Lab 7

Web Services





This week we learned how web services can provide useful data to web applications. In this lab you will use a web service to get new relevant data, transform it via XSLT, and display it in your application.




  1. Copy your Lab06 new Lab07 directory. Your main file should still be called index.html

2.      Here is what you what you want to have when you are finished.  Suggested plan of attach for getting there is below (read it before you start!):

    1. Try to keep the functionality from your previous lab (e.g. don’t start over and delete things, but you don’t have to fix things either.  Talk to the instructor if you have a reason to modify this).
    2. There should be a button(s), link(s), or something to click or interact with such that when you click on one the following happens:
      1. You use AJAX to invoke a Perl/PHP proxy
      2. The proxy invokes a web service (you choose, see below)
      3. The web service returns XML to the proxy, which returns it to your HTML/JS application
      4. You transform that XML with XSLT (see details below).
      5. You display part of the transformed XML in your page.
      6. All of this should happen within the same HTML page (e.g. the URL up top should not change)
    3. The web service must return different results based on different data in your database.  For instance, if you have people, you might show weather for their hometown when you click on one.  If you have products, you might show related pictures when you click on it. Thus, the same web service will be invoked, but different data from you will yield different results.
    4. You may choose any web service (some exceptions below) that returns XML and that permits you to use it for free non-commercial use (though you will likely have to register). Start this early! You may have to wait for a “key”, or it may turn out the service doesn’t provide what you need. Details:
      1. Tip: to find web services. Click on “APIs” – then look for search options.  Search for those with  protocol of  SOAP, REST, or GET. You want the data format to be XML. NOTE: not all the services have the “protocol” and “data format” fields stored on this site – so you might not want to filter on those at first.  Start by looking at the categories to see if you can find something that looks useful.
      2. Try to pick a service that adds real usefulness to your site.  Talk to the instructor if you need ideas.
      3. You may not use the two services used as lecture examples ( for REST and Flickr for SOAP).  Note: Flickr also offers REST – if your application really calls out for photos, and Flickr is really what you need, you can try to convince the instructor to allow you to use Flickr via REST, subject to some additional requirements.
      4. Your must use a proxy that directly interacts with the web service (as the two examples in class did). For instance, you may not use one of the Google JavaScript libraries that directly adds a map and handles all the interactions behind the scenes.
    5. You must use XSLT to modify the XML that you get. It should transform the XML so that it fits in with your existing page. Don’t just display the XML that you get back! Style and appearance counts here.
    6. As always, your code must be commented!
    7. On your default.htm page, provide some good, very specific comments for a user (e.g. the instructor) on how to use your site.  This should be specific to this lab – e.g. how can I see that your site meets the requirements for this lab? For instance, what to click, what to enter, etc.
  1. Suggested plan of attack (see also helpful info at end)
    1. Do NOT follow the requirements above in order. Instead…
    2. First identify a web service and register (if necessary).
    3. Figure out how to access the web service via your browser (or a Perl proxy, if it’s SOAP).
    4. Save a sample XML result from the web service. You will have to turn this in.
    5. Write a XSLT transformation and test it on the sample XML file. Don’t forget to verify your XSLT file alone by loading it in a browser.
    6. Write the JavaScript to load the XML (from your static XML file), apply the XSLT to it, then insert some of the result in your page.
    7. Modify your JS to invoke the proxy to get the dynamic XML data (instead of fetching the static XML), then transform via XSLT and display on your page.

4.      Ensure your page works with Firefox. Having it work on IE is encouraged but not required.

5.      Ensure all your pages validate and that you have met all requirements.


NOTE: all HTML files must validate as XHTML without errors for full credit.  The penalty for a file that does not validate is 10%.

Helpful stuff

  1. See the plan of attack above!
  2. General debug strategy:
    1. First, run Perl from the command line and make sure it works (see below).  Include actual arguments so you can see it’s really working.
    2. Second, run Perl via the webserver directly, e.g. something like
    3. Finally, try it all from HTML via the browser.  If this doesn’t work
      1. Look first at the Error console!
      2. Use window.alert() to see what is happening.  In particular, check what URL you are actually using to invoke Perl.
      3. Did I mention looking at the Error console?
  3. As always, the “Error Console” in Firefox is invaluable.
  4. Perl is easier to debug via the windows command line. You should first check for syntax errors by just “checking” the file:
         perl –c -w
    Once that works run it for real:
         perl -w
    If needed, you can provide CGI arguments like this:
         perl –w “query=dogs&type=2”
  5. On the command line, database errors will usually appear automatically.  From the browser, they won’t – instead insert this as a debug:
         print $DBI::errstr;
  6. Useful SQL examples:
    2. INSERT INTO comments (USER_NAME, TIMESTAMP, COMMENT, PAGE) VALUES ('Jamie', '2006-09-27 11:30:00', 'hi', 2);
    4. INSERT INTO topics (TOPIC, OWNER) VALUES ('Cars', ‘Jamie’);
    5. Note: ID is automatically created with the table, no need to specify it.
  7. Do not use the die() function alone – the error it generates can’t be seen from your web page.



1)      All of your files for Lab07 should be in a folder called "Lab07" (without the quotes) on the Web drive.

2)      Your main page for Lab07 should be called "index.html" (without the quotes) and placed inside the folder Lab01.

3)      Your instructor will assume that your web pages are viewable at where XXXXXX is your alpha number. You should check that this URL is viewable and that everything works correctly from a computer where somebody else is logged in. If you've goofed and linked to a file on your X drive, this will help you catch it!

4)      All files must be complete and saved to your Web drive before you submit the hardcopy of your assignment. Do NOT modify your files after you have submitted your assignment.

5)      Turn in the following hardcopy on or before the due date, stapled together in the following order (coversheet on top):

a)      A completed assignment coversheet.  Your comments will help us improve the course.

b)      The first page of the output of the W3C validator, as run on the final version of your Lab07 HTML that does the new transformation.  This should show that your document correctly validated, but turn it in anyway if you can’t get your page to validate. 

c)      A printout of the source to your Lab07/index.html file (or other HTML file that has the new transformation).   Truncated lines are not acceptable – use Crimson Editor vice Notepad if needed for printing.  You could also paste into Microsoft Word etc. if needed.

i)        NOTE – turning in just the JavaScript fragment that does the transformation and insertion is acceptable if you wish.

d)      Printouts of external JavaScript files, if any.

e)      Printout of your Perl/PHP file that acts as a proxy

f)        Printout of sample XML returned by the web service you use.

g)      Printout of your XSL file