Slideshare.net (beta)

 
Post to TwitterPost to Twitter
Post: 
Myspace Hi5 Friendster Xanga LiveJournal Facebook Blogger Tagged Typepad Freewebs BlackPlanet gigya icons

All comments

Add a comment on Slide 1

If you have a SlideShare account, login to comment; else you can comment as a guest


Showing 1-50 of 1 (more)

Web 2.0 Mashups

From hchen1, 7 months ago

http://tinyurl.com/2flvsk

808 views  |  0 comments  |  1 favorite  |  41 downloads
 

Categories

Add Category
 
 

Groups / Events

 

 
Embed
options

More Info

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License
This slideshow is Public
Total Views: 808
on Slideshare: 808
from embeds: 0

Slideshow transcript

Slide 1: Web 2.0 Mashups Dr. Harry Chen CMSC 491S/691S March 3, 2008

Slide 2: Agenda  What’s Web Mashup?  How is it different from Web Portals and Web Information Aggregators?  Popular Mashup architecture  Key enabling technologies of Mashups  Legal and business issues

Slide 3: Mashup (web application hybrid) “In technology, a mashup is a web application that combines data from more than one source into a single integrated tool; an example is the use of cartographic data from Google Maps to add location information to real-estate data from Craigslist, thereby creating a new and distinct web service that was not originally provided by either source.” http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

Slide 4: Mashups and Mashups Music Mashups Web 2.0 Mashups

Slide 5: Good ideas behind Mashups  Allow information to be viewed from different perspectives (e.g., view real estate data on a map)  Combine data from multiple sources into a single unified view (e.g., compare gas prices in the neighborhood).  Enrich raw data with new information (e.g., view eBay real estate auction along with Zillow data)

Slide 6: These ideas are not new!  Web Portals: Yahoo! provide information of different kinds under a single unified theme.  Web Information Aggregators: CNET, Pricewatch.com, MySimon etc. provide price comparison services for many products.  RSS Readers: collect feeds from different news sites to create a news channel.

Slide 7: Mashup, old idea repolished?  Is Mashup an innovative new idea?  Are there any difference among Mashups, Web Portals and Web Information Aggregators?

Slide 8: Similar, but distinct Web Portals & Web Information Aggregators vs. Mashups Similarity Difference  Pull information from  Only Mashups creates different sources something new from the Provide a unified view existing information

Slide 9: Restaurants Example  Consider a Restaurant Review web site  A typical Web Portal or Aggregator  Collect reviews from multiple sources  Combine reviews into a single database  Build a new Web site for review search and recommendation An example from: http://webtrends.about.com/od/webmashups/a/web_mashup.htm

Slide 10: Restaurant Mashup App  Collect reviews from difference sites (including Web Portals)  Use Google Maps to locate the restaurant address and place their reviews on the map  New UI experience – browse restaurant reviews on a map.

Slide 11: Mashup Genres  Mapping mashups  Video and audio mashups  Search and shopping mashups  News mashups  Enterprise mashups  Mashups of Mashups (monster mashups)

Slide 12: Mashup Architecture

Slide 13: What’s involved Content Provider Content Provider Content Provider API Provider API Provider API Provider Mashup Site Client Web Browser

Slide 14: Content Provider  Provides data  May be the authority in these data (e.g., US government agency)  May ask for money to use the data  May invite the Web to contribute to and edit the data  May not provide open API for reading data Can you name a Content Provider?

Slide 15: API Provider  Provides API to access and modify the data  May the same organization that publishes the data (API Provider == Content Provider)  API are usually Web-based (HTTP)  May ask for money to use the API, usually its free. Can you name an API Provider who is not a Content Provider?

Slide 16: Mashup Site  Hosts the mashup application  Actual “mashup” may not occurred on the server – depending on the implementation  Server-side process  Client-side process  May license the use of data or API from the Content Provider or API Provider  May acquire data by scrapping Web pages Do you see any problems with mashups that rely on content scrapping?

Slide 17: Client Web Browser  Displays mashup pages to the user  May perform client-side “mashup” logic  JavaScript and ActiveX are usually required  Heavy use of JavaScript and ActiveX can cause cross-browser compatibility issue. What’s the role Flash technology in Web 2.0 Mashups?

Slide 18: Key Enabling Technologies

Slide 19: Technical issues to consider… Content Provider Interface for read/write data API Provider Programming language neutrality Light-weight data format representation Mashup Site Rich content & dynamic user interaction Client Cross-browser and multiple device platforms Web Browser

Slide 20: Key technologies  HTTP  Ajax  XHTML and CSS  REST  RSS Not a complete list. But, a majority of mashup webapps use these technologies. An overview for now. We will revisit them in more detail in the next few classes.

Slide 21: HTTP  Without HTTP, the Web won’t exist.  The protocol for communicating information on the Web  It defines 8 methods indicating the desired actions to be performed on a resource Can you name those methods? request Web Browser Web Server response

Slide 22: Key HTTP Methods  Some methods are key to enable REST programming (more on REST later)

Slide 23: HTTP in Mashups  Mashup applications usually read/write data via HTTP  Because HTTP is stateless, building mashup applications is not as intuitive as building desktop applications.  Sending data via HTTP has many advantageous. Can you name a few?  What if you are building an enterprise app

Slide 24: Ajax  Asynchronous JavaScript And XML  The idea is to enable interactive Web pages without requiring the browser to refresh. Modify the page content, without refreshing the page “Give me some data” JavaScript code “Here, data in XML” Web Server Browser

Slide 25: Ajax vs. tradition HTTP paradigm  In the tradition HTTP world  Every request results in a new page loading  Dynamic pages are created on the server-side  Data, format and styling are done on the server  In the Ajax world  The result of an Ajax call may only change a small parts of an existing HTML page  Server sets up the page structure, JavaScript code performs the content creation  Data, format and styling are done via JavaScript (CSS and XHTML)

Slide 26: Ajax in Mashups  The idea of Ajax plays an important role in the mashup culture – not the JavaScript part or the XML part of Ajax.  Ajax encouraged Web innovations  Goolge Maps  Porting desktop applications to the Web  Ajax make the Web more “useable” for the everyday people

Slide 27: XHTML and CSS  HTML tells your browser the structure of a Web page  CSS tells your browser about the format and styling of the page content  XHTML is an XML version of the HTML language Why do we need XHTML? What’s wrong with HTML?

Slide 28: XHTML and CSS in JavaScript  JavaScript is powerful Web programming language because it can exploit XHTML and CSS  JavaScript is support by all major Web browsers and it provides the API to parse XHTML pages and use CSS  You don’t use JavaScript to change page styles. You change page styles by using JavaScript to manipulate XHTML and CSS

Slide 29: XHTML and CSS in Mashups  XHTML provides the mechanism to “id” objects in a Web page and change their structural position in the page  Without XHTML, you won’t be able to move things around in the page without doing a “refresh”  CSS makes Mashup “pretty” and “usable”.  Diaglog box vs. a browser pop-up  Overlay HTML objects on the top of each

Slide 30: REST  Representational State Transfer  The goal is to allow web resources to be created, updated, deleted and retrieved using the existing HTTP methods.  REST is the enemy of RPC (Remote Procedure Calls)  Resources are identified by unique URL http://example.com/user/johnsmith

Slide 31: The CRUD model e.g., REST operation: http://example.com/user/johnsmith

Slide 32: REST in Mashups  REST simplifies the reading of data for Mashup applications.  You can build Mashups without using REST  IMHO. I like the idea of using URL to identify resources. But it’s unnecessary to take REST as the holistic approach to web development.

Slide 33: RSS  Really Simple Syndication  Allows frequently updated contents to be published in a common format

Slide 34: RSS in Mashups  RSS can be used a standard formation representation to share information between the Content Provider and Mashup Sites.  Provides key vocabularies to describe common data types on the Web  UseRSS to describe blog entries, news, podcasts, email messages etc.

Slide 35: Mashup Legal and Business Issues

Slide 36: Legal Issues  Should Mashup artists have the right to use any data published on the Web?  I’m breaking any copyright laws if I feature you flickr photos on my mashup page? Assuming that I’m don’t profit from the page.  Trespassing in Cyberspace: your mashup is overloading my server! See also: http://web.mit.edu/sloan-msa/Papers/4.5.pdf

Slide 37: Business Issues  Is it a good idea to build your start-up based on the Mashup idea?  What if your Content Provider pull the plug from you?  What kind of control do you have over the data?  What kind of legal liabilities do you have when “mashup” data from other sites?

Slide 38: Summary  A mashup is a web application that combines data from more than one source into a single integrated tool  It’s a unique technology because it creates something new from the data already exists.  Mashups are only possible because of the recently advancement in Web technology – Ajax, REST, XHTML, CSS and RSS.