Post on 12-Sep-2020
(C) 2002 sLAB Informationssysteme - http://www.slab.de
Ein Framework fürmobile Client/Server-Anwendungen
JUGS SIG Embedded JavaMichael Jerger, Peter Rudolph7. November 2002
(C) 2002 sLAB Informationssysteme - http://www.slab.de
Definitionen und Szenarien
Beispielanwendung
sLAB's Lösungskonzept
Beispielimplementierung
Ausblick
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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.
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
Definitionen und Szenarien
Beispielanwendung
sLab's Lösungskonzept
Beispielimplementierung
Ausblick
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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..
(C) 2002 sLAB Informationssysteme - http://www.slab.de
Definitionen und Szenarien
Beispielanwendung
sLab's Lösungskonzept
Beispielimplementierung
Ausblick
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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, ...
(C) 2002 sLAB Informationssysteme - http://www.slab.de
Definitionen und Szenarien
Beispielanwendung
sLab's Lösungskonzept
Beispielimplementierung
Ausblick
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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)
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
Action "Neue Adresse"
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
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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"
Action "Neue Adresse"
CreateAddress
EditAddress
Addressbook.Add
Cancel
Abort Commit
OK
ex
ex
1
2
3
grünorange
Namen der Operationsverwendeter Dialog
dunkelblauhellblau
eingebene WerteModellbezug
(C) 2002 sLAB Informationssysteme - http://www.slab.de
Definitionen und Szenarien
Beispielanwendung
sLab's Lösungskonzept
Ausblick
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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.
(C) 2002 sLAB Informationssysteme - http://www.slab.de
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: Peter.Rudolph@slab.de, http://www.slab.de