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:

• UA faculty resources on clickers
• UWM faculty resources on clickers 

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.

Project 2c

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

Due date: Mon, 12 Oct
Group project

Objectives

An understanding of

• Representational state transfer (REST)
• Dependency injection
  

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:

• Building Web Services the REST Way
• The Resource-Oriented Architecture
  

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

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

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.

• Increasing the heap size for Eclipse
• Increasing the permgen size for Eclipse

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.

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
  

Project 0

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.