Anwendungsanforderungen und Ziele

1. Transaction Synchronization for XML Data in Client Server Web ApplicationsStefan Böttcher & Adelhard TürlingUniversität Paderborn

2. Anwendungsanforderungen und Ziele E-Learning, E-Commerce, Marktplatz Client Web-Service pc1700 WWW externe Anwendung DB hp4000 • Datenrepräsentation: unterschiedliche Zielformate • Erreichbar auf verschiedenen HW/SW-Plattformen • Datenänderung auf dem Client • lange Transaktionen • mobile Clients / häufige Netzunterbrechungen

3. Anwendungsanforderungen und Ziele E-Learning, E-Commerce, Marktplatz Client Web-Service pc1700 WWW externe Anwendung DB hp4000 • Datenrepräsentation: unterschiedliche Zielformate XML • Erreichbar auf unterschiedlichen HW/SW-Plattformen HTTP • Datenänderung auf dem Client • lange TransaktionenOLLT • mobile Clients / häufige Netzunterbrechungen

4. Architektur und Technologie Web-Service externe Anwendung Client Web-Server & Mapping HTTP XML-Datenbank- Mapping für Queries & Updates Transaction-System XML- Daten XML DB Listener Commit XML • browse • read • update this / update any • delete this / delete any • insert Map optimiert / normal

5. Mapping-Alternativen XML-DB-Mapping XML-Database database driven XML-DB-Mapping model driven template driven • Struktur • mitliefern • table model • komplexe • Queries nötig object model + oft nur 1 Pfad für Queries nötig + je 1 Map pro Partner + mit / ohne Sortierung

6. Unterstützte Mappings XML-DB-Mapping database driven XML-DB-Mapping model driven object model + oft nur 1 Pfad für Queries nötig Unser Ansatz: Start-Element (Tabelle+Satz) + Integritätsbedingungen + gewünschter DB-Ausschnitt generiert DTD-Vorschlag + Map + je 1 Map pro Partner + mit / ohne Sortierung

7. Mapping-Beispiel ER-Diagramm zu DB-Schema Schema zu virtuellem XML-Dokument customer start: customer M 1 order order N N product product N 1 1 1 1 N 1 N supplier details supplier details Map

8. Vom Mapping generiertes XML-Dokument Schema zu virtuellem XML-Dok. Server: Virtuelles XML-Dokument < ?xml version=“1.0“ ... > < XMLServer > < customer a1=“...“ a2=“...“ > < order cid=“...“ pid=“...“ > < product a1=“...“ a3=“...“ > < supplier a2=“...“ a3=“...“ / > < details a1=“...“ / > < /product > < /order > < order cid=“...“ pid=“...“ > < product a1=“...“ a3=“...“ > < supplier a2=“...“ a3=“...“ / > < details a1=“...“ a2=“...“ / > < /product > < /order > < /customer > < /XMLServer > start: customer 1 order N product 1 1 1 N supplier details Map

9. XML-Fragmente zum Client Server: Virtuelles XML-Dokument < ?xml version=“1.0“ ... > < XMLServer > < customer a1=“...“ a2=“...“ > < order cid=“...“ pid=“...“ > < product a1=“...“ a3=“...“ > < supplier a2=“...“ a3=“...“ / > < details a1=“...“ / > < /product > < /order > < order cid=“...“ pid=“...“ > < product a1=“...“ a3=“...“ > < supplier a2=“...“ a3=“...“ / > < details a1=“...“ a2=“...“ / > < /product > < /order > < /customer > < /XMLServer > Client: XML-Fragment < ?xml version=“1.0“ ... > < XMLServer > < customer a1=“...“ > < order cid=“...“ pid=“...“ > < product a1=“...“ > < supplier a2=“...“ a3=“XY“ / > < details a1=“...“ a2=“...“ / > < /product > < /order > < /customer > < /XMLServer > Update

10. Reversibles (=umkehrbares) Mapping Schema zu virtuellem XML-Dok. Client: XML-Fragment < ?xml version=“1.0“ ... > < XMLServer > < customer a1=“...“ > < order cid=“...“ pid=“...“ > < product a1=“...“ > < supplier a2=“...“a3=“XY“ / > < details a1=“...“ a2=“...“ / > < /product > < /order > < /customer > < /XMLServer > customer 1 order N product 1 1 Update 1 N Enthält Updates und Keys auf dem Pfad zur Wurzel supplier details Keys: Map

11. Reversibles (=umkehrbares) Mapping XML-Fragment Änderungen auf dem Client : XML1 -> XML2 Map-1 Map Map Eindeutige Folge von DB-Operationen : DB1 -> DB2 Delete-Operationen: vollständige DB-Tupel Insert: Nullwerte für fehlende Attributwerte (sofern erlaubt) Alternativen: Key-Management bei Inserts ( API oder DB )

12. Optimierung: Unterscheide Client-Operationen mit / ohne Lese-Zugriff auf Daten aus der Datenbank Read: lies einen (aus DB generierten) Attributwert Browse: lies Strukturinformation oder einen aus der Map generierten Wert Update any: ( phone number ) – unabhängig vom alten Wert Update this: ( price ) - abhängig vom alten Wert Delete any: ignoriere alten Wert Delete this: lösche gerade diesen alten Wert Insert: füge Teilbaum ein

13. Differenzmengen zu Client-Operationen mit / ohne Lese-Zugriff auf Daten aus der Datenbank Read ( Node ) : read set = read set U { Node } ; Browse ( Node ) : - Update any ( Node ) : update set = update set U { Node } ; Update this ( Node ) : update set = update set U { Node } ; read set = read set U { Node } ; Delete any ( Node ) : delete set = delete set U { Node } ; Delete this ( Node ) : delete set = delete set U { Node } ; read set = read set U { Node } ; Insert (Fragment) : insert set = insert set U { Fragment } ;

14. Commit-Phase Client ruft: Server.requestCommit( read set, insert set, update set, delete set ) requestCommit( read set , insert set , update set , delete set ) { tBegin ; if ( hasChanged ( read set ) ) tAbort ; else { use map to update database ( insert set , update set , delete set ) if ( integrity violation or other DB-Error ) tAbort ; else t Commit ; } return Commit-status to Client ; }

15. Zusammenfassung • XML-Datenrepräsentation erlaubt unterschiedliche Zielformate • durch HTTP erreichbar auf unterschiedlichen HW/SW-Plattformen • vorhandene Alt-Datenbestände/Datenbanken integrierbar (JDBC) • Mapping flexibel wählbar • Datenänderung auf dem Client möglich • kommuniziert minimale XML-Fragmente • Synchronisation mehrerer Nutzer verschiedener XML-Sichten • Serverentlastung für lange Transaktionen: keine langen Locks • mobile Clients: keine Probleme mit häufigen Netzunterbrechungen • OLLT hat sehr gute Performanz in Client-Server Web-Umgebungen

16. Ausblick • XML-Datenrepräsentation erweitern um Code / SOAP • Mapping ist nicht beschränkt auf relationale DBMS: mit ID und IDREF erweiterbar auf OODBMS • serverseitige XML-Speicherung nicht notwendig aber möglich