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.