Monday, November 9, 2009

Project 3

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
clicker 500 channel 70
registered on channel 69
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.

Monday, September 14, 2009

Project 2c

Due date: Sat, 7 Nov
Group project

Objectives

An understanding of
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

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.

Monday, August 31, 2009

Project 2a

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

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:
(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.

Monday, August 24, 2009

Tentative weekly course schedule

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

Tentative project roadmap

  • 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