CS 388/433: Web Services Programming

Project 3

2009-11-09T19:02:00.018-06:00

Due date: Mon, 7 Dec (firm)

Group project

Objectives

An understanding of

message-based service integration
patterns of (message-based) enterprise application integration
Java Messaging Service (JMS)
Apache ActiveMQ framework

Project Description and Background

In this project, you will develop a message-based model of a simple student-response system (classroom clickers).

Classroom clickers are a simple, inexpensive way to bring interactivity into the classroom. A clicker is a hardware device that resembles a remote control but includes a small (usually LCD) display in addition to several response keys. Each classroom has its own channel to which students in the room should set their clickers. To query the students, the instructor opens a poll on the instructor console and verbally or visually expresses a multiple-choice question; the students then press the key on their clicker that corresponds to their answer and receive confirmation that their response has been received; the instructor then closes the poll, and no further responses are accepted. This process can then be repeated with other questions as needed.

Further background information is available here:

Functional Requirements

The device you will model in this project is described here.

Your system will have a simple text-based interface (CLI) to control the instructor console and the clickers. Valid commands are

clicker N channel C - set the clicker with the given number to transmit on the specified channel
clicker N respond R - send the specified response from the clicker with the given number and (asynchronously) report whether or not the system has confirmed that it received the response
classroom C open R - open a poll in the specified classroom with the given number of possible answers (numbered from 0 to R - 1)
classroom C close - close the poll and print the number of responses for each possible answer

In any one classroom, there can be at most one open poll, but polls in different classrooms can overlap in time. Also assume all clickers have already been registered.

Your system should be configured to include three classrooms numbered 70 through 72 and five clickers numbered 500 through 504. Here is an example session with such a system; system responses are shown in italics.

clicker 500 channel 69
channel 69 invalid
clicker 500 channel 70
clicker 500 respond 2
channel 70 not accepting answers
classroom 70 open 5
clicker 500 respond 7
channel 70 received invalid answer from clicker 500
clicker 500 respond 4
channel 70 received valid answer from clicker 500
clicker 501 channel 70
clicker 501 respond 2

channel 70 received valid answer from clicker 501

classroom 70 close
responses: {0=0, 1=0, 2=1, 3=0, 4=1}

Architectural and Other Nonfunctional Requirements

Please use the SoccerStadiumActiveMQ example from the repository as a starting point for all aspects of this project, including the text-based interface. Similarly to the example, your system should model classrooms and clickers as separate objects.

Furthermore, the following nonfunctional requirements apply:

The project is managed using Maven.
The system is configured using Spring.
Communication among components is provided using ActiveMQ (an embedded instance is recommended) through Spring's JMS support.
To increase reusability, the POJOs (components providing the logical functionality) should be architecturally separate from the wrappers that connect them with JMS and the CLI.
The system should include component-level unit tests of the POJOs as well as integration testing of the entire system. (The example above could be one integration test.) To facilitate integration testing, consider developing a console object with methods corresponding to the CLI commands and expected responses. The CLI itself would then become a thin layer on top of this console object.

Deliverables

Working code in the repository.
Also in the repository, detailed documentation of your architecture and implementation.

Please use the repository for your group for collaboration and notify me when your work is ready for me to review. No explicit submission will be required. Submission by email will not be accepted.

Tentative weekly course schedule

2009-08-24T17:27:00.012-05:00

Week 1

organizational matters
overview
introduction to computing with services (ch 1)
SOA versus programmable web
connecting to and combining existing services: in-class demo

Week 2

principles of service-oriented computing (ch 5)
connecting to and combining existing services: in-class demo (continued)

Week 3

programming web services (ch 3)
resource-oriented (REST) services (Restlet book ch 4)
project discussion

Week 4

project 2b discussion
test 1

Week 5

enterprise architectures (ch 4)
basic standards for web services (ch 2)
resource-oriented (REST) and process/flow-oriented (SOAP) views of services (Restlet book ch 4 and ch 10)
project 2b discussion (as needed)

Week 6

restful services
project 2b discussion

Week 7

WS-* standards
stateful services
SOAP
test 2

Week 8

SOAP
Apache CXF framework
project 2c discussion

Week 9

project 2c discussion
message-based integration

Week 10

message-based integration
project 3 discussion

Week 11

message-based integration
project 3 discussion
test 3

Week 12

semantic web

Week 13

semantic web

Project 2c

2009-09-14T15:44:00.088-05:00

Due date: Sat, 7 Nov
Group project

Objectives

An understanding of

process-oriented web services
simple object access protocol (SOAP)
Apache CXF framework

Functional Requirements

In this project, you will build the Recommendr web service, which helps you manage your Participatr group subscriptions based on your preferences expressed as keywords.

This stateful service will support the following operations:

setTermsRequired(terms: list of strings): void; in this and the following operations, the terms are words that occur in the group description
getTermsRequired(): list of strings
clearTermsRequired(): void
setTermsToAvoid(terms: list of strings): void
getTermsToAvoid(): list of strings
clearTermsToAvoid(): void
setMinGroupSize(size: int): void; -1 means no min
getMinGroupSize(): int
setMaxGroupSize(size: int): void; -1 means no max
getMaxGroupSize(): int
findMatchingGroups(): list of group URIs that match all criteria
findGroupsToAvoid(): list of group URIs that don't match at least one criterium
authenticateOnParticipatr(id: string, passwd: string): void // throws exception if unsuccessful
findMatchingUnsubscribedGroups(): list of URIs of unsubscribed groups that match all criteria (requires prior authentication)
findSubscribedGroupsToAvoid(): list of URIs of subscribed groups that don't match at least one criterium (requires prior authentication)
subscribeToMatchingUnsubscribedGroups(): void
unsubscribeFromSubscribedGroupsToAvoid(): void

Furthermore, you will build a simple command-line client for this service. This client allows you to invoke the operations of the service in the form

recommendr operation arguments

Extra Credit

For extra credit, use OAuth to give Recommendr access to Participatr accounts without Recommendr having to know the account passwords. (You will have to modify your Participatr service to support OAuth.)

Architectural and Other Nonfunctional Requirements

The following nonfunctional requirements apply:

The project is managed using Maven.
Both the service and client should be equipped with comprehensive test suites.
CXF is used to implement the web service and client using wsdl2java (included with CXF).
Spring session-scoped proxies are used for data in session scope (please see examples).

There are various CXF examples in the repository.

Deliverables

Working code in the repository.
Also in the repository, detailed documentation of your architecture and implementation.

Please use the repository for your group for collaboration and notify me when your work is ready for me to review. No explicit submission will be required. Submission by email will not be accepted.

Project 2b

2009-09-14T13:23:00.022-05:00

Due date: Mon, 12 Oct
Group project

Objectives

An understanding of

Functional Requirements

In this project, you will build the Participatr web service, which provides a very small subset of the functionality of Meetup.com, a social networking portal that facilitates offline group meetings.

This system will support the following entities:

Users, which have the following attributes

email address (also serves as unique ID)
first and last name
brief biography
groups in which the user is a member

Groups, which have the following attributes

unique name
description
user who created the group
group members

The system will support the following scenarios:

user signs up
user changes his/her full name and/or biography
user deletes his/her account
user creates new group
user changes description of group he/she owns
user deletes group he/she owns
user views list of groups with descriptions and membership count
user joins group
user views members of group he/she owns or has joined
user leaves group

These entities will be exposed as addressable, interconnected resources with suitable representations, and the scenarios will be supported through the uniform HTTP request interface.

Architectural and Other Nonfunctional Requirements

Overall, you should follow the architectural and design principles outlined here:

Your system should support at least these two representations for the user and group resources:

XHTML (suitable for a human user)
JSON (suitable for a programmatic client)

The key conceptual component of this project is to map the uniform REST verbs to the functionality described in the requirements. To some extent, we should do this part as a group in class and through the mailing list. The bookmarks example from chapter 7 of the REST book will help as well. Use the Spring-loaded version of this example, BookmarksRestletSpring from the course repository as a starting point; this post describes how to use cURL to interact with this service.

In addition, the following nonfunctional requirements apply to this project:

The project is managed using Maven.
Restlet is used to expose the given functionality in a resource-oriented form. Where appropriate, suitable representations should be included that make the (read-only) functionality accessible through a web browser (XHTML). Otherwise, the functionality should be accessible through cURL and through a suitable client also implemented in Restlet (JSON).
There should be a comprehensive test suite following the approaches found in the LinearRegressionRestletSpring and NumguessRestletSpring examples. JUnit should be used to automate both types of tests:

Direct, local, component-level unit and integration testing of the domain objects (User, Group, and related objects) and any services you layered on top of the domain objects. (Local JUnit testing of the Restlet resources is not required in this project. I have not yet figured out how to do that.)
HTTP-client-based system-level testing of the service using the JSON representation.

Persistence is provided using db4o.
Dependencies among components should be managed using the Spring framework.

Deliverables

Working code in the repository.
Also in the repository, detailed documentation of your resource-oriented architecture, including

a list of resources with a brief description of each
for each resource, the supported HTTP methods and their meaning/effect on the resource state (in terms of the scenarios listed above).

Please use the repository for your group for collaboration and notify me when your work is ready for me to review. No explicit submission will be required. Submission by email will not be accepted.

Project 2a

2009-08-31T14:02:00.052-05:00

Due date: Fri, 11 Sep
Individual project

Objectives

An understanding of

web service access through HTTP
authentication and authorization for web service access
web service access through specific client libraries

Familiarity with

Maven (mostly within Eclipse)
Google Data APIs (Javadoc reference for client libraries)
Atom Publishing Protocol (APP)

Part 1 (4 points)

Perform the following steps:

Create a Google account if you don't yet have one.
Sign into Google Base and create a few items through the web interface.
Following the ClientLogin documentation, use cURL to obtain an authorization token for your account (without using Captcha). For each request parameter, use a -d argument for cURL. Your response should contain three lines, one of which begins with Auth=. The following value is the authorization token you will use in subsequent requests.
Now take a look at your list of items using the following HTTP GET request (all on one line):

curl -H 'Authorization: GoogleLogin auth=YourToken' http://www.google.com/base/feeds/items/

In this list, you should see the embedded URLs of the individual items. Select and copy one of them. Now delete the item by submitting an HTTP DELETE request with the same Auth header as before directly to the item's URL.
Take another look at the list. The item you deleted should no longer be there.

Part 2 (6 points)

Perform the following steps:

Obtain a Google Base API key for installed applications.
Check out the GDataJavaClientTest example from the course repository, then update its Maven dependencies (right-click on project root node > Maven > Update Dependencies). There should be no more compile-time errors (as indicated by red Xs).
Enter your API key and your authorization token in the test/main.properties file. All the existing JUnit tests should now pass (run them by right-clicking on the project root node > Run As > JUnit Test).
Add another test method (with the @Test annotation) that does the following:

Insert several items of item type TestOnly, each with a float-unit attribute indicating the item's price.
Iterate through your feed and count the items with this item type and compute their average price. Use assertions to ensure that the item count and average price are as expected.
Iterate through your feed again to increase each item's price by the same percentage.
Iterate through your feed one more time to compute the new average. Check that it has gone up by the same percentage.
Iterate through your feed to delete all items you created at the beginning of this test method.
Iterate through your feed one last time to make sure the items are gone.

Deliverables

Part 1: Screenshot or other form of transcript of your complete command-line interaction with Google Base.
Part 2: Complete, working project with the additional test case.

Please follow these online submission instructions. Submission by email, especially to the mailing list, is highly discouraged.

Project 1

2009-08-31T13:12:00.012-05:00

Due date: Fri, 4 Sep
Individual project

Objectives

Installation of and familiarity with required software
An understanding of the HTTP protocol
Initial experiments with web service access

Part 1: Installing cURL

cURL is a command-line data transfer tool that supports HTTP, among several other common protocols. Therefore, it can play the role of a command-line web user agent (commonly called browser).

You should set up cURL in at least one of the following ways:

It should be installed by default on Mac OS X.
Install using the package management system for your platform, e.g., sudo apt-get install curl ca-certificates on Ubuntu.
Download an appropriate version for your platform with SSL support.
Use it remotely by logging on to one of the departmental hosts, random.cs.luc.edu or infinity.cs.luc.edu.

Test the HTTPS support of your cURL installation as follows. You need your own Delicious account or your own Twitter account.

curl -u yourid https://api.del.icio.us/v1/tags/get
curl -u yourid https://twitter.com/statuses/friends_timeline.xml

cURL will prompt you for the password. In either case, you should see a response in XML format (with lots of angular brackets). If you see any error messages pertaining to missing SSL support, double-check your installation and try again. If you don't have any bookmarks or friends, your response will be essentially empty, for example, <posts user="yourid" ...> </posts>, but that's still a successful interaction with the service.

Part 2: Installing Eclipse

We are using Yoxos to manage our Eclipse configurations. In particular, I have created a configuration for this class. To obtain a distribution for your OS based on this configuration:

http://ondemand.yoxos.com/geteclipse/start
Public Profiles > Loyola University Chicago
select complete-javaee-fall2009
press green arrow
press start download button

(You can also manage your own configurations on Yoxos and use this one as a starting point.)

If Eclipse runs out of memory, please follow these directions.

Deliverables

Screenshot or other form of transcript of your successful access to the Delicious or Twitter web service.
Screenshot of your Eclipse configuration showing the successful execution of a HelloYourname Java project that prints Hello Yourname.

Please follow these online submission instructions. Submission by email, especially to the mailing list, is highly discouraged.

Project 0

2009-08-24T15:56:00.004-05:00

Discussion Group Subscription

The first part of this project, due immediately, requires you to subscribe to the discussion group for this course. Keep in mind that you are responsible for being familiar with any information exchanged on this discussion group.

Linux Account Verification

The second part of this project, also due immediately, requires you to verify that your departmental Linux account works. (If you are a new student, you should have received email about your account.) This account is separate from your Loyola account and will allow you to use the lab machines as well as the cvs.cs.luc.edu server (we will use the CVS system for version control in conjunction with team-based development). If you have any problems with your Linux account, please contact our lab manager right away.

Group Formation

The last part of this project, due within about two weeks, requires you to form a project work group with other fellow students. The groups should be of size three. The groups should stay the same throughout the semester.
Once you have formed your group, please send me email containing a list of all group members with the user IDs for their departmental Unix accounts.
For each subsequent project, there will be one submission and consequently one grade per group.

Submission

There is no submission required for this project, other than sending the list of group members by email.

Tentative project roadmap

2009-08-24T16:42:00.001-05:00

connecting to and combining existing services: details TBA
implementing resource-based services: Restlet.org
implementing process-based (flow-based) services: Apache CXF
message-based service integration: Apache Camel
(time permitting) implementing agent-based and semantic web services: JADE, Jena

Course objectives

2008-01-28T17:58:00.008-06:00

The overall objective of this course is an understanding of service-oriented computing as an architectural approach for loosely-coupled distributed applications. Specific objectives include an understanding of

resource-, process-, and agent-based views of services
the implementation of service-based applications through service composition, coordination, and description
the use of service-based applications through service selection, engagement, and evaluation

Tentative weekly course schedule

2008-02-04T16:33:00.001-06:00

Week 1

organizational matters
overview

Week 2

distributed information systems

Week 3

middleware

Week 4

enterprise application integration
web technologies

Week 5

quiz 1 (after the lecture)
web services
basic web services technology

Week 6

basic web services technology

Week 7

service composition

Week 8

quiz 2 (after the lecture)
service coordination

Week 9

service composition using representational state transfer (REST)

Week 10

service composition using representational state transfer (REST)

Week 11

quiz 3 (after the lecture)
enterprise integration using asynchronous messaging

Week 12

enterprise integration using asynchronous messaging

Week 13

outlook

Organizational matters

2008-01-14T18:57:00.001-06:00

introduction
contact info
office hours
discussion group
prerequisites
grading criteria
textbooks

Software required for this course

2008-01-28T20:28:00.000-06:00

Here is an initial list:

If Eclipse runs out of memory, please follow these directions.

Further updates coming soon...

Project 0

2008-01-14T19:36:00.000-06:00

subscribe to the Google discussion group
form a project team of size 3 (preferred)

Project 2

2008-03-31T17:18:00.003-05:00

Due Date: Wednesday, 30 April (firm)

Group project

Functional and Architectural Requirements

In this project, you will have the opportunity to implement a resource-oriented reservation system. You should follow these requirements, using your web application from the previous semester as a starting point.

Overall, you should follow the architectural and design principles outlined here:

Your system should support at least two representations:

XHTML (suitable for a human user)
JSON or concise XML (suitable for a programmatic client)

Other Non-Functional Requirements

The project is managed using Maven.
Restlet is used to expose the given functionality in a resource-oriented form. Where appropriate, suitable representations should be included that make the functionality accessible through a web browser (XHTML). Otherwise, the functionality should be accessible through a suitable client also implemented in Restlet (JSON or XML).
There should be a comprehensive test suite involving direct and client-based testing (using the chosen data representation) of the available functionality.
Persistence is provided using Hibernate as in your web application starting point, or you may switch to db4o instead.
Dependencies should be managed using the Spring framework.

Submission

Please use the repository for your group for collaboration and notify me when your work is ready for me to review. No explicit submission will be required.

Project 3

2008-03-31T13:59:00.000-05:00

Due Date: Wed 9 April (outline); Mon 21 April (presentation)

Group project

Description

In this project, you will have the opportunity to investigate a topic of interest in the area of web services.

Given the remaining time of the semester and the length of each presentation, you are not expected to conduct an exhaustive study of your topic. The purpose of this project is for you to find and present some starting points for using a particular technology or discuss the utility of some general approach. Please consult with me if you have any questions.

Deliverables

This project consists of the following deliverables:

Brief outline of your presentation due on 9 April.
Brief (15-20 minutes) in-class presentation of your findings (followed by up to 5 minutes of questions) on 21 April or before.
Accompanying materials, such as electronic copies of your visual presentation, code examples, etc.

Possible topics

Here are some possible topics:

You are welcome to choose other relevant topics pending my approval.

Submission

Please refer to the online submission procedure. Each team is to make exactly one submission. Any written materials should be submitted either in PDF format or through Google Docs.

Project 1

2008-02-25T18:41:00.000-06:00

Due Date: Wednesday, 26 March

Group project

Functional and Architectural Requirements

In this project, you will have the opportunity to implement a service-oriented voter registration system. The system consists of the following components.

Voter registration web service with the following capabilities:

set current ZIP code (stored in HTTP session scope)
register a voter (stored persistently, generates a confirmation number)
check whether a voter is registered
modify a voter
remove a voter
list all registered voters

Voter registration client that exposes the capabilities of the web service through a simple command-line interface.

For each voter, at least the following information is captured:

confirmation number as unique key
name
zip code

Other Non-Functional Requirements

The project is managed using Maven.
Both the service and client should be equipped with comprehensive test suites.
CXF is used to implement the web service and client using wsdl2java.
Spring session-scoped proxies are used for data in session scope.
Persistence is provided using Hibernate.

References

Example projects

LinearRegressionMaven (442 repository)
CXF examples in 433 repository

CXF documentation
Hibernate documentation
Maven documentation

Submission

A repository for each group will be created shortly. No explicit submission will be required.

Project 3 presentations

2008-04-22T10:57:00.002-05:00

Blanche Faur and Bhavana Shanbhag: Java Open Single Sign-On (JOSSO)
Emily Brand, Aureliusz Rempala, and Fan Wang: Acegi/Spring Security
Seiya Kawashima, Eric West, and Paul Zolnierczyk: Google Web Toolkit (GWT)