1. Web Services & Widgets Godmar Back

2. 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

3. 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

4. Client Browser Source A http://www.lib.edu/sourceA Source C http://any.host.domain/sourceC Source B http://opac.lib.edu/sourceB Server-side Mash-Up Mash-Up Server http://mashup.lib.edu HTML C A Base Page B Base Server http://www.lib.edu

5. Client Browser Source A http://www.lib.edu/sourceA Source C http://any.host.domain/sourceC Source B http://opac.lib.edu/sourceB Proxy-Based Mash-Up C A Base Page B Proxy http://www.lib.edu/proxy Base Server http://www.lib.edu HTML+JavaScript XMLHttpRequest

6. Client Browser Source A http://www.lib.edu/sourceA Source C http://any.host.domain/sourceC Source B http://opac.lib.edu/sourceB Client-side Mash-Up Base Server http://www.lib.edu HTML+JavaScript C A XMLHttpRequest + XML/Text Same Origin Restriction + JSON XMLHttpRequest + XML/Text Same Domain Restriction No Domain Restriction Base Page B B (via hidden frame) External Service + JSON JSON Proxy http://any.where/ 

7. 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)

8. Examples Client-side integration in library OPAC – Nearly closed system – vendor allows very limited customization of HTML – http://addison.vt.edu:2082/ 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

9. 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

10. SUPPLEMENTARY SLIDES

11. 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

12. 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)

13. 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

14. Client Browser Source A http://www.lib.edu/sourceA Source C http://any.host.domain/sourceC Source B http://opac.lib.edu/sourceB Client-side Mash-Up Base Server http://www.lib.edu HTML+JavaScript C A XMLHttpRequest + XML/Text Same Origin Restriction + JSON XMLHttpRequest + XML/Text Same Domain Restriction No Domain Restriction Base Page B B (via hidden frame) External Service + JSON JSON Proxy http://any.where/ web services & widgets

15. Example Page on opac.lib.edu/page.html Can include JavaScript from anywhere: 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 anywhere web services & widgets

16. 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

17. 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 & exampleshttp://people.cs.vt.edu/~gback/js/ web services & widgets

18. 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

19. 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

20. 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!"); }); $(document).ready(function() { $("a").click(function(event) { alert("Thanks for visiting!"); });

21. 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]123 web services & widgets

22. 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 later web services & widgets