Ein Framework für mobile Client/Server-Anwendungen · 2002. 11. 9. · Produktentwicklung für Partnerfirma: Umfang 50 MJ viele sLAB Mitarbeiter verfügen über 2 MJ Erfahrung in

(C) 2002 sLAB Informationssysteme - http://www.slab.de

Ein Framework fürmobile Client/Server-Anwendungen

JUGS SIG Embedded JavaMichael Jerger, Peter Rudolph7. November 2002


Definitionen und Szenarien

Beispielanwendung

sLAB's Lösungskonzept

Beispielimplementierung

Ausblick


1.1 sLAB's Definition mobiler Systeme

Ein Mobiles Gerät ist ein "Remote I/O Device"

Datenbearbeitung auf dem Mobilgerät erwünscht

Zugriff auf zentralen Datenbestand (Backoffice)

Mobilgerät ist kein reines Anzeigegerät

Permanente Netzwerkverbindungen sind unrealistisch

Kosten für Verbindung bzw. Netzabdeckung

Applikation und Daten müssen lokal verfügbar sein

Die meisten Mobilgeräte sind als Browser ungeeignet

Gute Benutzerführung ist entscheidend für die Akzeptanzmobiler Software

Teile der Funktionalität des Backoffice sind verfügbar

Kleine Displays, eingeschränkte Texteingabe, etc. müssenberücksichtigt werden


1.2 Mobile Daten

Daten müssen gegen Diebstahl gesichert werden

sLAB's Definition mobiler Daten

Teile des Datenbestands werden geändert oder entstehenauf dem Mobilgerät offline (ohne Serververbindung)

Mobile Datensicherheit

Abgleichintervall von offline Daten liegt typischerweise imStunden- bis Tagebereich

Teile des Datenbestands können von mehreren Personenkonkurrierend geändert werden

D.h. verschlüsselte Speicherung und Kommunikation


1.3 Konfliktszenarien

Erzeugung

Änderung

Inkonsitenz

Derselbe Datensatz wurde mit anderen Daten von einemanderen Anwender erzeugt und bereits auf den Serverübertragen.

Ein anderer Anwender hat denselben Datensatz geändertund bereits auf den Server übertragen.

Der Datensatz ist in sich nicht konsistent, was aber aufdem Mobilgerät nicht ermittelt werden konnte.


ConflictManagement

BackofficeConnector

synchronize

Internet

work offline work online work offline synchronize

SAP, Oracle, etc.

Dynamischer Wechsel zwischen Online- und Offline-Zugriff auf Daten und Anwendungen

1.4 Verbindungsszenarien

Klassisch: online (Browser), offline (PIM)

Intermittierend



Beispielanwendung

sLab's Lösungskonzept


Ausblick


2.1 Beispiel einer Mobilen Anwendung

Eingabeunterstützung durch intelligente Textver-vollständigung (Textbausteine und Fachwörterbuch)

PDA mit GPS für Servicetechniker

Elektronische Erfassung der Auftragszettel

Führen eines Fahrtenbuchs und Ermittlung desKunden mittels GPS

Gelegentliche Synchronisation mit Auftragserfassungüber Netz und Handy


2.2 Beispiel einer Mobilen Anwendung

1. ArbeitsbeginnSynchronisation mitdem Backoffice:Termine, Kundendaten,Artikelliste,Gerätebeschreibungenund Textbausteine fürFehlerbeschreibungen

2. Start zum Kunden

Position mittels GPS ermittelnund als "Start" kennzeichnen.Fahrzeug und Kilometerstanderfassen.

3. Ankunftbeim Kunden

Position mittelsGPS ermitteln und als"Ankunft" kennzeichnen.Auswahl des Kunden aus Listealler Kunden im Umkreis.

4. Während der Arbeit

Ausfüllen des elektronischenArbeitszettels. Auswahllistenund Textbausteine reduzierenden Tippaufwand.

5. Auftrag erledigt

Kunde unterschreibt denAuftragszettel: Display,digitale Signatur, Handy,etc.

7. Feierabend

Überspielen der tagsübererfassten Daten.

8. Konfliktlösung

Meist durch einenKollegen im Innendienst:Doppelt erfasste Kunden,Tippfehler imAuftragszettel,etc.

6. GPRS-ÜbertragungÜbermittlung der aus demFahrzeug entnommen Teile.Evtl. Empfang des nächstenAuftrags..



Beispielanwendung



Ausblick


3.1 Herausforderungen Mobiler Projekte

Volumen der Nutzdaten muß für das Mobilgerät reduziertwerden (Partitionierung)

Intermittierendes Szenario

Lokale Datenhaltung auf dem Mobilgerät

Gelegentlicher Abgleich mit dem Backoffice

Datenbearbeitung auf dem Client

Zusätzliches Konfliktpotential

Konflikterkennung oft erst lange nach der Entstehung(Zeitspanne zwischen Eingabe und Abgleich)

Datentransfer

Geringe Bandbreite beim Zugriff über Handy/GPRS

Sicherung gegen Abhören (Verschlüsselung)

Speicherkapazität

Meist sehr geringe Speicherkapazität


HTML-Browser als alternativer Client, z.B. auf PC im LAN

3.2 Herausforderungen Mobiler Projekte

User-Interface für Zielplattform optimieren

Eingeschränkte Eingabe- und Darstellungsmöglichkeiten

Oft ungünstigere Umgebung als im Büro: Lärm,Lichtverhältnisse, Ablenkung

Geschäftslogik und Datenmodelle für diverse Clientsund Server nur einmal implementieren

Weniger Codieraufwand

Vermeidung von Fehlern bei der Implementierung des Clients


Geschäftslogik auf dem Mobilgerät istidentisch mit Server oder daraus generiert

Auf dem Mobilgerät werden alle Aufrufe derGeschäftslogik aufgezeichnet und später auf demServer abgefahren

GUI ist für das jeweilige Mobilgerät optimiert

3.3 Konzepte / Ansatz sLAB

BusinessLogic

BusinessLogic

HTML InterfaceBackofficeServer 1

BackofficeServer 2

ServiceRecorder

ServiceReplayer

ServerSynchronisation

For Mobile Deviceoptimized GUI

LocalStorage

Server'sStorage

Datenfluß in

Pfeilrichtung

Mobile


3.4 Weitere Server-Bausteine

Connectoren

Anbindung des Backoffice über Java Connector API, JDBC, WebServices ...

Erzeugung geeigneter Informationen für dem ConflictManager sowie Konflikterkennung

Benutzer- und Aufgaben-spezifische Datenpartitionierung

Mobile Devices Management

Verteilen von Anwendungen auf Mobilgeräte

Speicher- und Performance-Optimierung für Zielplattform (z.B. Dialoglayout)

Implementierung als Plug-In für Standard System Management Systeme wie z.B. HP OpenView, ...



Beispielanwendung



Ausblick


Motivation

4.1 EJBs auf dem Mobilgerät

Mobilgerät stellt weniger Ansprüche an den EJB Container,z.B. Single User, kein Background-Task nötig

Evtl. automatisches Generieren mobiler EJBs beim Deployment

Viele Geschäfts-Anwendungen auf Basis von EJB implementiert

Vorgehen (2 Diplomarbeiten)

Portierung eines OpenSource EJB Containers (OpenEJB)

WebServices als Schnittstelle zum EJB

Mobile EJBContainer

EJBContainer

HTML InterfaceBackofficeServer 1

BackofficeServer 2

ServiceRecorder

ServiceReplayer

ServerSynchronisation

For Mobile Deviceoptimized GUI

LocalStorage

Server'sStorage

Datenfluß in

Pfeilrichtung

Mobile

WebService WebService

XML zur Be-schreibungdes GUI


GUI

Mobile Data Objects

Interface

Sync

Manager

Local Storage

BusinessObject

Manager

Trans Pool

EJB Container

Webservice

Server's Storage

ConflictStrategies

ConflictManager

TransLog

Kommunikation

über SOAP

Client Mobile Device Server

EJB EJB

EJB EJB

EJB EJB

EJB EJB

TransactionManager

Action

ReplicationStrategies

Datenfluß in

Pfeilrichtung

Mobiler EJB Container erlaubt Übernahmeder Geschäftslogik auf das Mobilgerät

4.2 Mobiler EJB Container

WebServices als Standard-Schnittstelle

HTMLInterface


4.3 Bausteine (Mobilgerät)

Transaction Manager

Speichert Zugriffe auf Geschäfts-logik (Actions) im Transaction Log

Ordnet gespeicherten Actionseinen Dialog-Kontext zu

Zuordnung der Actions zuTransaktionen

GUI

Mobile Data Objects

Interface

Sync

Manager

Local Storage

TransLog

Client Mobile Device

EJB EJB

EJB EJB

TransactionManager

Action

Action

Zugriff auf Geschäftslogik: implementiert einen Prozeßschritt

Kann auch Benutzerinteraktion enthalten

Entscheidet, ob auf MDO oderdirekt auf den Server zugegriffenwird


4.4 Mobile Data Objects

Transparente Persistenz

Einheitliche Schnittstelle für alle Mobilgeräte/Netzwerktypen

Verbindungstypen always-on, offline und intermittierend

Leichtere Konflikterkennungund -beseitigung

Speichern des Dialog-Kontextsmit jedem Bearbeitungsschritt:

--> dem Anwender oder Konflikt-bearbeiter kann leicht ver-anschaulicht werden, was dieUrsache des Konflikts ist.

GUI

Mobile Data Objects

Interface

Sync

Manager

Local Storage

TransLog

Client Mobile Device

EJB EJB

EJB EJB

TransactionManager

Action


BusinessObject

Manager

Trans Pool

EJB Container

Webservice

Server's Storage

ConflictStrategies

ConflictManager

Server

EJB EJB

EJB EJB

ReplicationStrategies

HTMLInterface

Replication Strategies

Legen fest, wann was repliziert wird, z.B. zu einer festenUhrzeit oder bis sich ein bestimmter Client gemeldet hat

Conflict Manager

Löst Konflikte oder delegiertsie an einen Sachbearbeiter

Business Object Manager

Liest Transaction Pool ausund führt Transaktionen aus

Übergibt Konflikte an denConflict Manager

Conflict Strategies legen fest,wie die Konflikte im einzelnenbehandelt werden

4.5 Bausteine (Server)


4.6 Beispiel-Action: Ablauf

Neue Adresse im Addressbuch anlegen

Die Action wird über einen Button ausgelöst

Action "Neue Adresse"

CreateAddress

EditAddress

Addressbook.Add

Cancel

Abort Commit

OK

ex

ex

1

2

3

1

2

3

3 Operationen, eine davon ist ein Dialog



CreateAddress

EditAddress

Addressbook.Add

Cancel

Abort Commit

OK

ex

ex

1

2

3

//---- 1: create empty addressopID = AddressBook.OPERATION_NEW; newAddress = this.addressBook.call(opID, null);

//---- 2: edit new address (dialog)newOpId = StringID.getInstance(NAMESPACE, "NewAddressDialog");dlgCtrl = CallableDialogController.getInstance();newAddress = dlgCtrl.call(newOpId, newAddress, dialogContext);

//---- Third Operation: add new address to address bookif (newAddress != null) { result = this.addressBook.call(AddressBook.OPERATION_ADD, newAddress);

}

actionLog.addOperation(opID, this.addressBook, newAddress, dialogContext);

actionLog.addOperation(newOpId, null, newAddress, dlgCtrl.getChangedModelData(), dialogContext);

actionLog.addOperation(AddressBook.OPERATION_ADD, this.addressBook, newAddress, dialogContext);

4.7 Beispiel-Action: Code


4.8 Beispiel-Action: Transaction-Log

<TRANSACTION ID="clientID1035930821707" transSequence="transSeq" targetnamespace="de.slab.dtfaf.tm" xmlns:ns1="de.slab.dtfaf" xmlns:ns0="de.slab.dtfaf.demo.simple"> <OPERATION ID="ns0: " ownerRef="ns0:Book1" > </OPERATION> <OPERATION ID="ns0: " ownerRef="" dialogRef="ns1:AddrDialog"> <PARAM ID="ns0: " value= /> <PARAM ID="ns0: " value= /> <PARAM ID="ns0: " value= /> </OPERATION> <OPERATION ID="ns0: " ownerRef="ns0:Book1" dialogRef="ns1:AddrDialog"> </OPERATION></TRANSACTION>

NewAddress

NewAddressDialog

AddAddress

modelRef="ns0:103"dialogRef="ns1:AddrDialog"

modelRef="ns0:103"

modelRef="ns0:103"

Name "Fritz"City "12345 Demostadt"Street "Müller"


CreateAddress

EditAddress

Addressbook.Add

Cancel

Abort Commit

OK

ex

ex

1

2

3

grünorange

Namen der Operationsverwendeter Dialog

dunkelblauhellblau

eingebene WerteModellbezug



Beispielanwendung


Ausblick


4.1 Status - Heute

„Mobiles KnowHow“ ist vorhanden

Produktentwicklung für Partnerfirma: Umfang 50 MJ

viele sLAB Mitarbeiter verfügen über 2 MJ Erfahrung in mobilen Projekten

sLAB war verantwortlich für Architektur und Projektleitung

Anwendungen und Prototypen mit KundenZiel: Referenzen aufbauen

„Mobiles KnowHow“ wird erweitert

5 abgeschlossenen Diplomarbeiten + 2 laufende

Forschungprojekte beantragt (Fraunhofer Institut, Intershop)

Weitere Projekte und Piloten

Framework

KnowHow in einzelnen Bausteine bereits implementiert

„InHouse-Benutzung“, kein fertiges Produkt

Partner: Fraunhofer Institut, Uni München, Uni Tübingen, Uni Jena,Intershop, Hamburger Hafen e.V.


4.2 Roadmap

In einem Jahr (je nach Marksituation)

Weitere Projekte abgeschlossen

Einzelne Referenzen verfügbar

Wichtigste Bausteine des Frameworks implementiert

Suche nach OEM Partnern,

z.B. Erweiterung eines bestehenden Warenwirtschaftssystemsum eine mobile Komponente

In 2-3 Jahren (falls Bedarf am Markt)

„Mobile Produkte“ über OEM-Partner

Erstellung eines vollständigen „Mobilen Frameworks“

Vertieb über Partnerfirmen

sLAB ist Technologielieferant in Form von Mobilen Produktenund/oder Framework

Kontakt: [email protected], http://www.slab.de

Documents

Ein Framework für mobile Client/Server-Anwendungen · 2002. 11. 9. · Produktentwicklung für Partnerfirma: Umfang 50 MJ viele sLAB Mitarbeiter verfügen über 2 MJ Erfahrung in