Ein Praxisbericht

J2ME-Bankanwendung für mobile Endgeräte

Oliver Lauer

1999 beschäftigte sich die Anwendungsentwicklung der Sparkasse KölnBonn erstmalig mit Java und dachte über den Einsatz der kommenden und noch brandneuen J2EE nach. Zu dieser Zeit war aber in den Sun-Laboren in Kalifornien die J2EE bereits kalter Kaffee. Hier entwickelte man bereits die Idee des „Java überall“ intensiv weiter und konzentrierte sich mit hohem Aufwand auf die kommende J2ME. Aber erst Ende 2003 läutete das Erscheinen des neuen Nokia 6600-Handy im deutschen Weihnachtsgeschäft das Ende der Eiszeit im mobilen Bankgeschäft ein.

Mit der J2ME entwickelte sich besonders im Jahre 2000 nicht nur im IT-Umfeld ein Hype rund um alle mobilen Themen – WAP und UMTS waren in aller Munde. Heute wissen allerdings nicht nur IT-Firmen wie Sun und die Banken, wie dieser Boom endete. Die Sparkasse KölnBonn z.B. stellte den Betrieb einer eigenen WAP-Mobilbanklösung wegen sehr geringer Nutzerzahlen schnell wieder ein. Erst mit dem eingangs erwähnten Nokia-Handy wurden die Entwickler der Sparkasse durch große neue Displays, schnellere Datenverbindungen, einfachere Bedienungselemente und die aktualisierte Java-Umgebung ermutigt, einen erneuten Versuch zu wagen. Darunter verstand man keine Utilities oder Spiele, sondern eine Bankanwendung für den sicheren und sinnvollen Breiteneinsatz.

Zielsetzung und Strategie – gegen schlechtes Wetter

Ausgehend von der ungünstigen Wetterlage für mobile Bankanwendungen der vergangenen Tage sind die Hauptvoraussetzungen für einen erneuten Versuch, „die Stadtsparkasse dem Kunden in die Tasche zu stecken“:

  • geringer Aufwand, die Anwendung zu realisieren, weil der Bedarf nicht absehbar ist
  • Untersuchung der Akzeptanz beim Kunden in einem produktiven Testumfeld

Um eine hohe Akzeptanz bei Kunden zu erreichen, mussten die im Folgenden aufgelisteten Mängel der Vergangenheit beseitigt und gleichzeitig die neuen Möglichkeiten der MIDP 2.0 genutzt werden:

  • unkomfortable Bedienung
  • langsam in der Anwendung und Datentransport
  • proprietär in der Sicherheit und Softwareverteilung
  • hohe Kosten der Anwendung

Des Weiteren sollte eine mobile Bankanwendung die Chance bieten, durch kostengünstige Anwendung ein Medium für das breite Publikum zu werden. Hohe Übertragungskosten sollten als Akzeptanzhindernis unbedingt ausgeschlossen werden. Zudem sollte eine mobile und neue Bankanwendung ohne Netzverbindung – offline – funktionieren können. Möglichst viele Endgeräte sollten einsetzbar sein, hierbei sollten auch Palms und Pocket PCs mit der gleichen Anwendung und vor allem mit identischem Executable bedient werden können. Zu guter Letzt sollten die vorhandenen Entwicklerkenntnisse und die vorhandene Entwicklungsinfrastruktur ohne wesentliche Anpassungen und neue Investitionen in Ausbildung verwendet werden.

Die Bankfachlichkeit ist altbekannt – Windstille

Bei der umgesetzten Bankanwendung handelt es sich im Grunde um die klassische Homebanking-Anwendung, wie sie aus dem Internet bekannt ist. Die Authentifizierung und Autorisierung erfolgt über die bewährte PIN/TAN-Systematik. Die Anwendung ermöglicht folgende Anwendungsfälle:

  • Kontostand anzeigen
  • Finanzstatus abfragen
  • Umsätze anzeigen
  • Überweisungen ausführen
  • Überweisungsvorlagen erstellen und pflegen
  • Konten löschen und hinzufügen
Architektur erfüllt die strategischen Anforderungen – die Wetterkarte

Wie im Grunde für jedes Projekt essenziell, war auch in diesem Fall die Softwarearchitektur maßgebend für die Erfüllung der Anforderungen. In der ersten Version sollte keine Business-Logik neu entwickelt werden. Für alle oben genannten Anwendungsfälle waren ausgereifte Services vorhanden. Voraussetzung war, dass diese sicher und über offene Schnittstellen angeschlossen werden können. So sind die wichtigen Transaktionsservices des Retail-Banking der Sparkasse KölnBonn über SSL-geschützte Web Services erreichbar. Wichtige Internetanwendungen nutzen die gleichen Dienste. Somit musste man sich keine Gedanken über die Anwendungssicherheit machen, weil diese Web Services über das bekannte PIN/TAN-Verfahren authentifizieren und autorisieren und durch ihren Einsatz im Internet über eine bereits abgenommene und produktiv getestete Sicherheitsqualität verfügen.

Somit war die Hälfte der Arbeit getan, trotzdem bot sich eine direkte Einbindung der Web Services nicht an. Obgleich die nächste J2ME/MIDP-Version die Web-Services-Integration enthalten wird und durch optionale XML-Pakete auch proprietär diese Services im Handy hätten eingebunden werden können, hätte ein solcher Ansatz das wichtige Ziel des kostengünstigen und schnellen Klienten zunichte gemacht. Zwar ist mit Einsatz der GPRS-Datenübertragung (vorher GSM) die Datenübertragung schon ISDN-ähnlich schnell geworden, das „geschwätzige“ SOAP-Protokoll hätte hier aber kontraproduktiv gewirkt.

Ein Web-Services-Aufruf einer Kontoumsatzabfrage schickt ca. 25-50 KB über die Leitungen und verursacht somit GPRS-Kosten in Höhe von ca. 45-90 Cent (ohne Flatrate – Standard-Vodafone-Vertrag – 08/2004). Ebenso wäre mit einem solchen Ansatz die Antwortgeschwindigkeit durch das Parsen des SOAP XML auf der Clientseite und durch das hohe Datenvolumen negativ beeinflusst worden. Wie bekannt, ist die XML-Verarbeitung in der Regel eine CPU-intensive Angelegenheit, vor allem auf Geräten, welche wie Mobilfunktelefone über reduzierte CPU-Ausstattungen verfügen.

Abb. 1: Übersicht über die Server-Architektur von SK Handybanking 1.0

Es wurde beschlossen, das Web Service XML über eine zwischengeschaltete Apache-Tomcat-Instanz zu komprimieren und nur komprimierte CSV-basierte Daten an den Klienten zurück zu schicken. Ein eigenentwickeltes kleines Java-Framework, basierend auf J2SE 1.4, Tomcat 5 und Apache übernimmt den Aufruf der Web Services und das Parsen der Anfrage und der Antwort. Zwischen dem Handy und der oben genannten Zwischeninstanz werden nur kommaseparierte Werte ausgetauscht. Damit konnte das Datenvolumen bei allen Anwendungsfällen im Durchschnitt auf 1 KB und somit auf Mobilfunkkosten in Höhe von ca. 1,9 Cent pro Aufruf reduziert werden. Allerdings musste durch diesen Ansatz der Nachteil in Kauf genommen werden, dass der Klient genau diese proprietären Nachrichtenformate kennen muss.

Darüber hinaus wurde durch diesen Intermediäransatz eine Möglichkeit geschaffen, den Klienten mit über die Web Services hinaus gehenden Informationen zu versorgen bzw. verschiedene Web Services auf dem zwischengeschalteten Server zusammenzufassen und dem Klienten diese als einen Service anzubieten. Die Abteilung Online-Vertrieb erkannte im Laufe des Entwicklungsprojektes diese Möglichkeit als eine Form der Informationsanreicherung als positiv an.

Oben beschriebene/s Anforderungen und Vorgehen bedingten den Rich-Client-Ansatz nach Meinung des Projektteams als beste Lösung. Obwohl eine Webanwendung bekannte Vorteile hat, Browser in den Handys immer besser werden (siehe Opera für Series 60-Handys) und die Postbank aktuell mit einer neuen WAP-Lösung auf den Markt gekommen ist, hätte eine solche die Ziele nicht erfüllen können.

Messungen von verschiedenen WAP-Ansätzen ergaben, dass das 10 bis 40 fache Datenvolumen im Vergleich zu unserer komprimierten Individuallösung übertragen wird und entsprechende Kosten und Geschwindigkeitsnachteile in Kauf genommen werden müssen. Das ist zum jetzigen Zeitpunkt ein nicht akzeptabler Nachteil von webbasierten Lösungen, zusätzlich zu dem Nachteil der nicht vorhandenen Offline-Fähigkeit von Weblösungen.

Ebenso sind die Browserimplementierungen der Handys heute noch sehr unterschiedlich und bringen bei weitem mehr Implementierungsunterschiede als die vergleichbaren Desktop-Browser mit sich. Da mit einer Rich-Client-Anwendung möglichst viele Geräte und nicht nur Symbian- oder Motorola-Phones mit C++ oder VB.NET erreicht werden sollten, konnte die Wahl nur Java, genau genommen J2ME heißen. Hierbei griff das Entwicklungsteam auf das verbreitete Profil MIDP zurück und konnte durch die Wahl von Java ebenso auf breites und jahrelanges Know-how aufbauen.

Erfahrene J2ME-Kenner werden nun mit Sicherheit nach der Version fragen. Die Sparkasse KölnBonn hat sich für MIDP 2.0 entschieden und hierbei bewusst eine Vielzahl von bereits verfügbaren MIDP 1.0-Geräten ausgeschlossen. Diese Entscheidung wurde getroffen, weil der Zielsetzung entsprechend auf offene Standards in der Verteilung und in der Sicherheit zurückgegriffen werden sollte und weil die kostengünstige Verbreitung der MIDP-2.0-Handys ausreichend schnell vonstatten gehen wird. Außerdem war man der Meinung, dass Kunden für ein komfortables mobiles Banking ein großes Farbdisplay brauchen und dieses dann erst mit den neuen MIDP 2.0-Handys zur Verfügung gestellt werden wird.

Geschrieben von
Oliver Lauer
Kommentare

Schreibe einen Kommentar

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