Methoden komfortabler Datenbankanbindung für Mobile Devices

Transkript

1 Methoden komfortabler Datenbankanbindung für Mobile Devices Torsten von Osten (pdv TAS) DOAG 2008 pdv Technische Automation + Systeme GmbH, Seite

2 Agenda Vorstellung Mobile Devices Datenbankanbindungen Apex Listener DEMO Fragen & Antworten

3 Eckdaten pdv TAS

4 Eckdaten C1 Group

5 Mobile Devices - ein heterogenes Umfeld Desktop - und Serverumgebung Weitgehend standardisierte Hardware Windows, Linux, und ein wenig OSX als OS Es stehen diverse plattformübergreifende Programmiersprachen zur Verfügung (java, python, ruby...) Native DB-Treiber/Clients für fast alle Plattformen (OCI/ODBC) Java und JDBC geht immer!

6 Mobile Devices - ein heterogenes Umfeld Umgebung mobiler Devices Unterschiedliche proprietäre Hardware- Designs Starke Koppelung von Hardware und OS Diverse OS - Eigenentwicklungen der Hersteller Jedes OS ist auf eine oder wenige Programmiersprachen begrenzt Keine plattformübergreifende Sprache Nur wenige Plattformen werden durch einen nativen DB-Treiber unterstützt Kein Platzhirsch!

7 Mobile Devices - ein heterogenes Umfeld Smartphone OS weltweit (Gartner 2011/Q2)

8 Mobile Devices - ein heterogenes Umfeld Smartphone OS regionale Unterschiede

9 Entwicklungsmethoden für Mobile Devices Nativer Entwicklung- vs. allgemeiner Entwicklungsansatz Der native Ansatz Zugriff auf alle Hardware- und OS-Funktionen Natives Look & Feel bei der GUI Schnelle Ausführungszeiten Ggf. nativer DB-Zugriff Für jede Plattform ist eine eigenständige Anwendung zu entwickeln

10 Entwicklungsmethoden für Mobile Devices Der Web-Applikationsansatz Weiterverwendung bestehender Anwendungen Meist jedoch Anpassungen am Rendering der Oberfläche nötig Wahl der Programmiersprache nach eigenem Belieben incl. Frameworks für den DB-Zugiff und Unterstützung aller Datenbanken Konnektivität zum Server bei jeder Benutzerinteraktion notwendig Seiten müssen jedesmal neu geladen werden Sehr beschränkter Zugriff auf Geräte- und Betriebssystem Funktionen

11 Entwicklungsmethoden für Mobile Devices Der HTML5 (Javascript) -Ansatz Erweiterung der GUI Möglichkeiten Download der kompletten Anwendung beim Start Kein Nachladen der Anwendung (Seiten) Jedoch sind nun Zugriffsmethode auf die zentrale Datenbank vom Client aus notwendig HTML5 lässt Ansatzweise Zugriffe auf Geräte- Hardware zu (z.b. GPS, lokale DB) Noch nicht vollständig in den Browsern umgesetzt (z.b. Zugriff auf die Kamera) Kein differenziertes Sicherheitskonzept für den Gerätezugriff durch das OS Frameworks wie Sencha Touch oder jquery Mobile verfolgen diesen Ansatz

12 Entwicklungsmethoden für Mobile Devices Der generative Ansatz Entwicklungstools generieren native Anwendungen aus der gleichen Codebasis Framework stellt über eine API -Zugriffe auf Geräteund OS -Funktionen zur Verfügung Code läuft meistens auf dem Device in einem Interpreter mit Hooks auf die native GUI und Gerätefunktionen Zum Teil um eigene Funktionen erweiterbar Dadurch ist ein Zugriff auf weitere native Bibliotheken möglich Z.B. Cocona, PhoneGap oder Titanium Mobile

13 Komfortable Datenbankanbindung Definition von Komfortabilität: Mächtige API? High-Level-Funktionen? Allgemeingültigkeit? oder soll es einfach nur simpel sein?

14 Datenbankanbindung - nativer Treiber Oracle Net Treiber OCI / ODBC Kaum Unterstützung mobiler Plattformen JDBC Möglich bei OS mit Java-Unterstützung z.b. Android JavaME JavaFX Sicherheitsprobleme bei mobiler Netzwerkinfrastruktur

15 Infrastruktur mobiler Devices Funknetze WLAN und GPRS Kommunikation über das Internet Virtual Private Network (VPN) Administration Sicherheitsbedenken bei Datenbank-Server mit direkter WLAN- oder Internetanbindung Zugriff für alle DB-User Beliebige Statements ausführbar => Middleware zwingend erforderlich

16 Oracle Database Lite Middleware (Mobile Server) zwischen Datenbank und Mobile Device Client-seitige lokale Datenbank z.b. SQLite DB Mobile Client Komponente nötig Synchronisiert lokale DB mit Server-DB Anwendung funktioniert damit völlig autark Mobile Client Komponente nicht für alle Plattformen erhältlich (z.b. nicht für ios) zusätzliche Lizenzkosten

17 SOAP Webservices Simple Object Access Protocol (SOAP) Standardisiertes Protokoll Basiert auf XML und HTTP Als Service auf der Middletier implementiert Sehr flexibel und allgemein einsetzbar Abbildung komplexer Datentypen möglich Viel Kommunikationsoverhead und relativ komplex Parsen und Verarbeitung der XML-Daten insbesondere auf mobilen Devices ist lastintensiv

18 RESTful Webservices Kein Standard, kein Protokoll sondern eine Architektur Implementierungen basieren auf Standards wie HTTP, URI, JSON etc. Leichtgewichtiger als SOAP Ressourcen, deren Instanzen mit Methoden verändert werden können, stehen im Mittelpunkt bei HTTP (GET, POST, PUT und DELETE) Passt gut zu relationalen Datenbanken Ressourcen = Entities Methoden (Select, Insert, Update, Delete) Beispiel eines Zugriffes:

19 RESTful Webservices Datenformat nicht vorgegeben XML, JSON,... JSON am stärksten verbreitet schlank und einfach aber keine Typen-Prüfung Das ETag Versionsidentifikator im HTTP-Header für die entsprechende Ressource Prüfung auf Änderungen einer Ressource auf dem Server Verwendung im If-None-Match Request- Header-Attribut => HTTP Not modified Umsetzung von Optimistic Locking

20 Oracle Apex Listener J2EE-Alternative für den Oracle HTTP Server und modplsql als Apex- Middleware-Proxy Notwendig bei Apex-Internet-Applikationen oder im RAC-Betrieb Standalone Betrieb oder als Applikation im J2EE Server Middleware zur deklarativen Definition von RESTful Services Unabhängig von Apex einsetzbar Security Oracle Single Sign-in integriert Container Managed Security des J2EE-Servers Alle Mechanismen des Apache im Proxybetrieb (ReverseProxy) anwendbar

21 Oracle Apex Listener Definition der GET-, POST-, PUT- und Delete Resource-Handler durch einfache SQL-Abfragen oder PL/SQL-Blöcke SQL-Abfrage-Ergebnisse werden automatisch in das JSON oder CSV -Format konvertiert Parameter können einzeln für die URI oder dem Request-Header deklariert werden. Beim HTTP-Request mitgegeben JSON- Strukturen werden automatisch als Parameter gemappt Standardparameter für z.b. den Status-Code der HTTP-Response Achtung: Groß-/Kleinschreibung beachten NULL-Werte fehlen in der JSON-Struktur

22 Oracle Apex Listener ETag Unterstützung Zwei Varianten Automatischer Secure Hash Individuelle SQL-Abfrage Kaum von Oracle dokumentiert Nur eine Erwähnung wofür es da ist, aber nicht wie es funktioniert /implementiert ist Beim GET wird das IF-NONE-MATCH -Tag ausgewertet und ggf. mit 304 -Not modified geantwortet Automatische Unterstützung von Optimistic Locking ist unklar

23 DEMO DEMO

24 Fragen und Antworten DANKE Torsten von Osten pdv Technische Automation + Systeme GmbH Dorotheenstraße Hamburg Telefon: vonosten@pdv-tas.de Web :