1 / 22

Web Services & Widgets

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

kedem
Download Presentation

Web Services & Widgets

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related