Web Services & Widgets

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. Base Serverhttp://www.lib.edu Source A http://www.lib.edu/sourceA Mash-Up Serverhttp://mashup.lib.edu Source Bhttp://opac.lib.edu/sourceB HTML Source C http://any.host.domain/sourceC Client Browser Base Page A C B Server-side Mash-Up

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

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

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/ • (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. Base Serverhttp://www.lib.edu Source Bhttp://opac.lib.edu/sourceB HTML+JavaScript Same Domain Restriction Same Origin Restriction External Service Source A http://www.lib.edu/sourceA XMLHttpRequest + XML/Text XMLHttpRequest + XML/Text JSON Proxyhttp://any.where/ Client Browser Base Page A Source C http://any.host.domain/sourceC B C B (via hidden frame) No Domain Restriction <SCRIPT> + JSON <SCRIPT> + JSON Client-side Mash-Up web services & widgets

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

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] 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