SUCHE NACH OBJEKTEN
Prof. Dr. Clemens H. CapUniversität Rostockclemens .cap (at) uni-rostock (dot) dewww.internet-prof.de
Vortragender: Martin Garbe
GI Fachgruppe Datenbanksysteme und InformationRetrieval8. und 9. Mai 2008, Bamberg
Von den Problemen des Semantic Webzu den Chancen der JOPPA Architektur
Probleme des Semantic Web
Zu schwergewichtig, weil Relativ komplexe Syntax (XML, Namespaces, vieles explizit) Aufwendiges Reasoning (F-Logik, OWL-*) Viele Co-Technologien (RDF, SparQL, RIF, RDFS, Hohe Anforderung an Meta-Info (Ontologie, Schemata)
Daher Erfolge vornehmlich in engeren Spezialbereichen Akzeptanz in "großer" Community geringer als Social Web / Web 2.0
Community Akzeptanz lt. Technorati"Semantic Web" gegen "Web 2.0"
Community Akzeptanz lt Technorati"Semantic Web" gegen "Social Web"
Community Akzeptanz lt Google Trends"Semantic Web" gegen "Web 2.0"
Community AkzeptanzLt. Google Scholar
1. Social Web 2.110.0002. Web 2.0 699.0003. Semantic Web 354.000
Community Akzeptanz lt Ikon Teppich
Prognosen für die Zukunft
Das aktuelle Web 2.0 ist der letzte große Umbruch im Web mit User Generated Content zum "Socialnet" Anbindung der realen Außenwelt zum "Internet der Dinge"
Semantic Web Funktionen werden entstehen durch Socialising und Wisdom of Crowds in den Inhalten: bottom up weniger durch F-Logik, RDFs, SparQL, OWL
so schade das wissenschaftlich gesehen ist !! vermutlich eher durch Microformate, Annotationen
Ausgangspunkt
Ausgangspunkt
Einfache Metadaten: Objekte mit Attributen
Kleine Objekte: Bis 20 Attribute, komplett typisch 1kB
Einfachste Queries: Nach QBE Ansatz Konjunktion von Value-Queries und Range-Queries auf
paarweise verschiedenen Attributen Ggf. noch Bloomfilter Queries (Zugehörigkeit zu Maske)
Antwort darf unpräzise sein Liefert zu viel: Client-seitiges nachfiltern Liefert zu wenig: Keine vollständige Abdeckung erwartet
Keine Relationen und keine Joins
Geringe Tiefe der Klassenhierarchie Most specific class meist bekannt: Suche "PKW" nicht "KFZ"
{ class: "PKW", age: {min:10, max:20} }
AusgangspunktBeispiele
eBay Temporale Restriktion: Beschränkte Gültigkeit Suche auf most specific class
Amazon Standard-Buchsuche (nicht komplexes IR)
Kinoprogramm / Restaurant / Mietwohnung Lokale und temporale Restriktion Kleine Objektanzahl
Abdecken von 95 % derConsumer Queries
Lösungsansatz bisher
Objekte: Von DB via SQL in ein RowsetLogik: Von Rowset via Treiber zu PHP Result-Array
Von Result-Array in ein PHP Business-ObjektTemplate: Von PHP Objekt via Smarty nach HTML + JS
Layout: Von HTML via Parser nach DOM
Lösungsansatz bisher
Rowset
DB
PHP Obj
PHP Array
HTMLJs
DOMJs Obj
HTMLJs
HTTP
Lösungsansatz bisherKritikpunkte
Zu viel String Processing – zu aufwendig
Zu viel am Server, zu wenig am Client – skaliert schlecht
Zu viele Nahtstellen – Impedanz Mismatch
Vgl: SQL / PHP / Javascript / HTML – Injection Attacken
Zu viele Sprachen – zu hoher Lernaufwand
Business Logik in 2 Sprachen
Am Client: In Javascript für ein 1. Matching (optional)
Am Server: In PHP / (SQL) für ein 2. Matching (mandatory)
Zu wenig konzeptuelle Trennung
Bsp: CSS / JS / HTML, JS / PHP, Model / View
Aber: Struts (schwer !), Spring, Tapestry, Stripes
Zu viele Technologien Weitere Nachteile
XML, XHTML DTD, Xschema XML Namespaces XPath, Xpointer XForms XSL / XSLT / XSL-FO XQuery, XUpdate XLink RDF
Keine uniforme Browser-Unterstützung (XSL, XPath)
Zu häufiges Parsen nötig
Editoren: Ja, nur für Spezialist
Doppelt großer Overhead
DB-Mapping problematisch
(Attribute, Aufwand, Query)
Lösungsansätze bisherWarum nicht XML?
Rowset
DB
PHP Obj
PHP Array
HTMLJs
DOMJs Obj
HTMLJs
HTTP
Js ObjJs Obj Json RPC
JsBusiness
JsBusiness
UTETemplat
e
JsonDB
Ähnliche Ansätze in der Literatur
Parallele Entwicklung ähnlicher Ideen bei anderen Gruppen
jsdb: Javascript DB nur Client-seitig
Aptana: Pure Js Development Serverside Js in SCRIPT Tag eingearbeitet, somit Spaghettis Keine Objektabtrennung
Persistent Javascript und Persevere DB Ansatz stärker traditionell Kein Templating
ÜbersichtBenutzte Technologie-Bausteine
Json-RPC: MiddlewareSchiebt Js Objekte hin und her
UTE: UTE ist eine Template EngineWichtig: Clientseitiges Templating !
Joppa: Object PersistenzJavascript Object Persistent Programming Architecture
ÜbersichtGesamtablauf der Anwendung
Client sendet QBE-Objekt
Server antwortet mit
1. Daten-Objekt und
2. Template-Funktion
Präsentation durch Anwendung der Js Funktion auf Objekt
Effekt: Client-side templating, skaliert besser
Und: Js Funktionen sind Domänen-weites Look %& Feelwird 1x geladenDamit: Sehr einfaches Skinning möglich
Business Logik: Server-side und Client-side in JavascriptKann sogar identischer Code sein !Geht auch wenn Objekte "Paragraphen" sindBsp: Wikis, Blogs, Annotationen
Vorteile von Js / Json
Am Client universell verfügbar Einfache Objektnotation Json – selber Js, daher nur "eval" OO (Prototypen-basiert, keine Typprüfung) Dynamische Attribute flexibler als in C++, Java Kein Mapping Problem wie bei XML: Content vs. Attribut Syntax leichtgewichtig Co-Technologien oftmals trivial (Bsp: JPath) Funktionen sind first class citizens (Speichern in Variable) Interpreter ist Teil des Sprachumfangs Stark steigende Akzeptanz der Community Als RFC 4627 standardisiert Sicher gegen Cross-Site Scripting (a long story told in one PPT bullet)
{ fname: "Clemens", lname: "Cap", lectures: ["net", "java", 11] }
Json RPCDie Middleware
Klassische Middleware, vgl SOAP, Corba, Sun-RPC
Client sendet request (Js-Objekt, als Json-Text)
Server sendet response (Js-Objekt, als Json-Text)
Synchron oder asynchron (dann mit Continuation handler)
Multi-request möglich (ein Transport (http) Call hält viele requests -
dann single oder stream response)
Stream-response möglich (response aus mehreren Chunks)
call ( "get", qbeObject );call ( "get", qbeObject, handler );call ( [ { "get", q1 }, { "put", q2 } ] );
UTEWas ist ein Template?
UTEWas ist ein Template?
Ein Template ist Inhalt mit LöchernLöcher durch Attribute eines Objekts ("Context") gefüllt
Wir brauchen also Konstante Templates (Inhalte ohne Löcher) Attribut-Ausdrücke (JsonPath; ctx.person.name)
Conditional Templates Benannte Templates Repetitive Templates
je 2 davonliefern Turing
UTEWas ist ein Template?
Konstantes Template <html> . . . Das ist ein Auto der Marke {$.auto.marke} mit {$.auto.ps} $ repräsentiert Kontext Objekt, Teile in { . . . } sind Js-interpretierbar
Conditional Template Joe geht in die {if: $.kid.age > 6, then: "Schule", else: "Kindergarten"}
Weitere Entwicklung, wie man sie sich üblicherweise vorstellt . . .
UTEDie Fallgruben im Design
Fallgrube 1: Designer muß programmieren
Inhalte mit if - then - else - for - while - try usw. angereichert
Fallgrube 2: Stringverarbeit. Programm erzeugt Design
Programm mit Escapements und string processing
x .= "<A href=\"".$url."\">".$text. usw…
Fallgrube 3: Imperative Sprache erlaubt Seiteneffekte
Ohne Disziplin entsteht M – V – C Mixtur
Bsp: Bluthochdruck gehört ins M, nicht ins V
Daher: Etwas anders weiterentwickeln
UTEIdeen
Stärkere Trennung: Separate Entities (Files, Regions, Sections) {if: $.age > 6, then: "Schule", else: "Kindergarten", id:"Institution"}
oder ohne id-Attribut in entsprechender Datei / Objekt (DB) speichen Joe geht in die {apply: "Institution", to: $.kid}
Einschränkung im Sprachumfang: Reines Json-PathOptimale Prädikate: Testen ob Wert vorhand oder nullAkzeptable Prädikate: Seiteneffektfreie bool. Funktion auf ContextUnerwünschte Präd. : Alles andere
UTEWas ist ein Template?
Ein Template ist eine Funktion
die aus einem Kontext Objekt
ein neues Kontext Objekt macht
Liefere an den Client
1. Kontext Objekt (Ergebnis der Query)
2. Funktions-Biblio (seit Betreten der Domäne im Cache)
Client erzeugt daraus (DOM)-Objekt = HTML-Seite
UTEBasis-Templates
Konstantes Template = Konstante Funktion { const: 44 } { const: "Zuse" } { const: john.kid[3].age } { const: { vname:"Konrad", nname:"Zuse" } }
Sequentielles Template = Funktor von n Funktionen {seq: [ tmpl1, tmpl2, tmpl3, … ] } { seq: [ {"Konrad"}, {"Zuse"} ] }
Kompaktere Notation dazu <html> . . . Er ist {$.john.kid[3].age} alt Wir hatten damals bereits eine Funktion mit const und seq !!
UTEBasis-Templates
<html>
{$.head}
{$.body}
</html>
Kontext: $.head $.body
<h1>{$.heading}</h1>
{apply: "articles", $.articles}
Kontext: $.articles ist array of articles,
diese haben weitere Attribute
<h2> {$.titel} </h2>
<div> {$.news} </div>
<ul> {apply: "links", $.links} </ul>
<hr>
PersistenzMeta-Prinzip: Schwein ja, Müll nein
PersistenzMeta-Prinzip: Wissenschaftlicher
Kein Anspruch an Anspruch an
Algebraische Vollständigkeit
Normalformen
Effizienz für alle Queries
Effiziente Joins
Langfristige Archivierung
Transaktionale Korrektheit
Hoher Recall, hohe Precision
Abdeckung genannter Use Cases
Chance auf sinnvolle Struktur wirdnicht dauerhaft und total versaut
Flexibles Schema
Do the best you can
PersistenzElemente des Schemas
Klassen Dienen semantischer Gruppierung ( isA, subClass )
Jede Klasse hat generischen Typ zugeordnet
Typen string, number, boolean, null
array
object
reference via OID referenziert
weak als Substruktur inkludiert
Query, Load, Store, Instanziierung & co. nur nach most specific classes Via Use Case Annahmen und GUI gewährleistet
PersistenzSicht des Clients
Erlaubt ist für Attribute
additional zusätzliches Attribut, das der Typ nicht vorsieht
nullable jedes Attribut darf (in DB & Client) fehlenfehlt $OID, dann nicht persistable, nur templatable
pending funktionalwertiges Attribut (Js Funktion)Attribut wäre vorhanden, Wert wurde nicht geladenAufruf der Funktion ( stub ) lädt Wert dynamisch
nach
Erlaubt ist für Methoden
Alles Dh: Fehlt, Parameter-Signatur falsch, Exceptions, usw.
Grund Server bereitet für Client korrekt aufClient kann beliebig sich und andere betrügenServer muß Client-Daten ohnehin massiv prüfenDem Client ist partial load gestattet (nullable,
pending)Pending load kann fehlschlagen
PersistenzMethoden
Als Js Text in Schema / Typdefinition enthalten
Dynamisch dazugepatched über Js Prototype-Chain über Reflection Methoden__noSuchMethod__
Aus Sicht des Betreibers Am Server korrekt vorhanden Am Client ohnehin nicht zu garantieren
PersistenzSicht des Servers
Instanziieren: oid new ( registeredClassId, [ templateObject ] ) Server generiert OID, speichert Klasse (& Typ), init nach Template
Speichern:object.persist ( [ jsonMask ] ) Object kennt eigene OID in $OID Geschriebene Attribute: Alle - außer jsonMaskierte & pending
(nicht mit null überschreiben, wenn nicht sicher weiß daß null ist)
Laden: object load ( oid, [ jsonMask ] ) Relativ zu opt. Json-Mask Ausdruck als Typ-Filter (Col Liste im SELECT)
Was wird eager (ie. sofort) geladen ? Was wird lazy (ie. pending als stub) geladen ?Was wird nicht geladen ? (Attribut null)
Cave: null: ist nullvs. nicht geladen
PersistenzImplementierungs-Strategien
Jede most-specific Klasse wird durch eine Tabelle umgesetzt reference Typen: Durch OID simple Typen: Durch Spalte weak Typen: Durch flattening array Typen: Durch separate Tabelle pending:Durch Js Code Generierung
für Client additionals: Durch Json Text
Damit nicht mehr (effizient) durchsuchbar
Cave: array of contentobjects, refs, simple ?!?
person.name.first = "Joe"
Ergebnis
Persistenz-Architektur für Javascript Objekte
Homogen: Durchgängig, Client & Serverseitig Javascript-Nutzung
Skalierung: Templating-Aufwand am Client, skaliert besser
Konzeptuell: Klare, konzeptuelle Trennung eines MVC – Ansatzes
Realisierungsstand Json RPC 95% implementiert, PHP Server UTE 60% raw prototype Persistenz 30% proof-of-idea (MySQL, PHP)