Web Services & Widgets

joeneetscompetitiveΑσφάλεια

3 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

179 εμφανίσεις

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

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

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

<SCRIPT> + JSON

XMLHttpRequest

+ XML/Text

Same Domain Restriction

No Domain

Restriction

Base Page

B

B

(via hidden frame)

External Service

<SCRIPT> + JSON

JSON Proxy

http://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 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

<SCRIPT> + JSON

XMLHttpRequest

+ XML/Text

Same Domain Restriction

No Domain

Restriction

Base Page

B

B

(via hidden frame)

External Service

<SCRIPT> + JSON

JSON Proxy

http://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 anywhere

web 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 later

web services & widgets