web services & widgets godmar back. mash-ups applications that combine information from...
TRANSCRIPT
Web Services & Widgets
Godmar Back
Mash-Ups
• Applications that combine information from different sources in one web page
• Different architectural choices– Server-side mashups – with or without proxy– Client-side mashups
• Widgets: higher-level, easy-to-use markup that is processed and hides mash-up implementation from user
Considerations
• Where should information be integrated?– Dedicated mashup page vs. existing page/application
• How much control does user have over origin server?– Full control vs. limited control
• (HCI-aspect) What is the user’s level of programming skills?– JavaScript expert vs. cut-and-paste/non programmer
Client Browser
Source Ahttp://www.lib.edu/sourceA
Source Chttp://any.host.domain/sourceC
Source Bhttp://opac.lib.edu/sourceB
Server-side Mash-Up
Mash-Up Serverhttp://mashup.lib.edu
HTM L
C
A
Base Page
B
Base Serverhttp://www.lib.edu
Client Browser
Source Ahttp://www.lib.edu/sourceA
Source Chttp://any.host.domain/sourceC
Source Bhttp://opac.lib.edu/sourceB
Proxy-Based Mash-Up
C
A
Base Page
B
Proxyhttp://www.lib.edu/proxy
Base Serverhttp://www.lib.edu
HTM
L+Ja
vaSc
ript
XMLHttpRequest
Client Browser
Source Ahttp://www.lib.edu/sourceA
Source Chttp://any.host.domain/sourceC
Source Bhttp://opac.lib.edu/sourceB
Client-side Mash-Up
Base Serverhttp://www.lib.edu
HTM
L+Ja
vaSc
ript
C
A
XMLHttpRequest + XML/Text
Same Origin Restriction
<SCRIPT> + JSON
XMLH
ttpR
eque
st
+ XM
L/Te
xt
Same Domain Restriction
No Domain Restriction
Base Page
BB(via hidden frame)
External Service
<SCRIPT> + JSON
JSON Proxyhttp://any.where/
Creating A Client-Side Mash-Up
• Engineering Challenges– Lack of module support and namespace separation– Easy for widget code to collide with base page code (and
with each other)– Origin must trust widget source (widget code may XHR
back to origin)– Correct handling of concurrency and asynchrony (JS
should load in parallel, services should be contacted in parallel)
– Browser dependencies (usually use a JS library such jQuery)
Examples
• Client-side integration in library OPAC– Nearly closed system – vendor allows very limited
customization of HTML– http://addison.vt.edu:2082/– (most recent implementation – supports full encapsulation
and namespace-clean bootstrapping of jQuery + Google services)
• Older widget examples – MAJAX, Google Book Classes– libx.org/majax– libx.org/gbs
Rest of Lecture
• Can do Code Walk through• Follow along, experiment
• Or can implement example: does anybody have a sample page they want to see a service integrated?
web services & widgets
SUPPLEMENTARY SLIDES
Design Considerations
• Will focus on scenarios where:– Have limited control over HTML– Interact with vendor-provided & other JavaScript
code• Issues:– Namespace hygiene– Parallelism/Latency– Inversion of Control
web services & widgets
Same Domain Restriction
• Web origins are characterized by (protocol, hostname, port) combination
• Each web page is associated with an origin• Web pages may load JavaScript code from anywhere• (No matter where JavaScript code is loaded from); JavaScript
code can make unrestricted connection only back to origin• Model is intended to protect users from malicious websites
that may attempt scraping of websites to which a user has stored credential (such as in cookies)
• Since JavaScript code can still be loaded from anywhere, services must be modeled as serving JavaScript code (JSON-P)
The JavaScript Sandbox
• Restricts what JavaScript can do– Can only make XML HTTP Requests to origin of document – (not
origin of .js JavaScript!)• Does not restrict where to read JavaScript code from• Sandbox is usually avoided by encoding information as
JavaScript code– JSON turns data into JavaScript code
• If a service provides JSON, it can be used within pages from any domain– But you must trust JSON source – you’re passing on any privileges
(cookies, etc.) with respect to origin domain to include JavaScript
web services & widgets
Client Browser
Source Ahttp://www.lib.edu/sourceA
Source Chttp://any.host.domain/sourceC
Source Bhttp://opac.lib.edu/sourceB
Client-side Mash-Up
Base Serverhttp://www.lib.edu
HTM
L+Ja
vaSc
ript
C
A
XMLHttpRequest + XML/Text
Same Origin Restriction
<SCRIPT> + JSON
XMLH
ttpR
eque
st
+ XM
L/Te
xt
Same Domain Restriction
No Domain Restriction
Base Page
BB(via hidden frame)
External Service
<SCRIPT> + JSON
JSON Proxyhttp://any.where/
web services & widgets
Example
• Page on opac.lib.edu/page.html• Can include JavaScript from anywhere:
<script src=“http://opac.lib.edu/code.js”><script src=“http://google.com/jsapi”>
• JavaScript code (no matter where it came from!!!) can make XHR (XML, HTTP, Text) only to opac.lib.edu
or *.lib.edu with domain trick• JSON requests – which equal including JavaScript
code – can go anywhereweb services & widgets
Serving JSON
• (Best case): Server was designed with JSON in mind. – Returned objects have nice, logical structure
• (Often reality:) JSON output was added as an afterthought– E.g., XML2JSON conversion – JSON is often
awkward– Or, 2json conversion of internal PhP or Python
objects
web services & widgets
JavaScript (The Language)
• Can do simple things easily, but also allows sophisticated designs
• Has many sharp edges – ways to shoot yourselves in the foot– Scoping, closures, semantics of ‘this’
• See http://people.cs.vt.edu/~gback/js/ for discussion & examples
web services & widgets
JS Frameworks
• Many libraries: jQuery, Prototype, Mootools, etc. etc.• Some libraries focus only on simplifying interaction
with DOM in a page (jQuery)– Removal of any browser dependencies
• Others provide methods to do object-oriented programming
• For libraries: Juice
web services & widgets
Inversion Of Control “Callbacks”
• Hollywood Principle:– Don’t call us, we call you
• Especially in connection with web services:– Call this function when a request completes
• Makes code difficult to read: code does not execute in textual order– Actual order is unpredictable: depends on which
data is cached, how long requests take
web services & widgets
jQuery
• Entire library resides in single function object called ‘$’– Yes, it’s a function and an object – can be called $(…) and
dereferenced $.method– $() takes a selector – similar to CSS - and finds in page, or
creates out of thin air, HTML elements– Returns a jQuery object, which combines a “selection” of
elements with methods to operate on these elements:• Manipulate them, traverse, get text, attributes, etc. etc.• Can be chained: $().next(…).click(…)• Does everything on all selected elements
– Provides a number of methods for AJAX etc.web services & widgets
$(document).ready(function() { $("a").click(function(event) {
alert("Thanks for visiting!"); }); });
Bootstrapping
• Assume that we only have single entry point• Load all JavaScript dynamically– In parallel
• Two critical points:– “document.ready” – sometimes called “DOM Ready”
• All elements have finished loading, but resources (images, flash, etc.) have not
– Window.onload – all images have finished loading• Don’t usually want to wait until that happens
• Complex issue, see [1], [2], [3]web services & widgets
Bootstrapping (2)
• Simplified approach: Load everything via DOM script insertion– including jQuery;– Write scripts to register 2 groups of callbacks:
“onDocumentReady”, “afterDocumentReady”– execute callbacks on document.ready() in order
• Some Google APIs must be loaded via Google loader; so load Google loader, then APIs– Execute callbacks on document.ready or Google’s
‘setOnLoadCallback()’, whichever is laterweb services & widgets