SRT Cloud Synchronization Module Architecture

Project Overview

We have an existing web based application that allows users to create service requests and save drafts locally, and when the request data is completed the user can submit the data via email.

The current app is built with Java, runs on a local / embeded jetty server and uses a local h2 database. The only time it needs internet access is when submitting the request.

We'd like to enhance this application to have cloud sync feature.

Competition Task Overview

The purpose of this challenge is to design the best solution to enable data synchronization with cloud server. At a high level, these are the key objectives:

• Oracle-based centralized data
• Cloud deployment of the application so it is accessible from anywhere on the network
• Local deployment of the application for anyone who wants offline capability
• Synchronization to and from central data store whenever possible (when local system is used again while online, check for data updates)
• Conflicts may occur, but only for the offline devices.  Also conflicts are very unlikely due to the fact that data is silo-ed by user.  If a single person is entering conflicting data in two places at the same time, there are bigger problems than data synchronization
• There are multiple options for conflict resolution, most of which would be fine.  Preference should be for implementation cleanliness

Detailed Requirements

• The current application runs locall on jetty and uses h2 database, the cloud server is a windows server 2008 R2 which has tomcat 7 and Oracle 11.2
• The new application needs to be able to to be deployed either on cloud or run locally (as it currently is)
• The local data storage part should stay as is, but when user is online, the appliation needs to be able to sync its data to the server
• In the new version users will have to login (though that can be remembered). All data remains separate from other users, but the database is otherwise shared. So add a user_id column to identify which data to use. When offline, last login will be used and remembered. After login, we will read a field from the request header which will identify the user, this identity is used when we sync data to the oracle database on the cloud. We'll also be able to get email address, first name and last name from the header, we need to save these into the profile.
• The architecture needs to be extensible (or needs to be really clear on how we can extend this solution), since the code you're looking at is just phase 2 of the application, and we have phase 3 & 4 going on in parallel which will add more data / tables.
• The user should be able to work offline and save data locally to the h2 database. But when online they will be able to sync data from / to the server database (Oracle). If the user uses a new computer the user will have to login and data on server will be synced to local database. Note, a request is immutable once submitted, so synchronizing completed requests should be simple.
• The solution should support synchronization of draft reqeusts too, this is more challenging since there might be conflicts. The client will want a clean solution that is simple rather than complicated. Better to let the user be responsible for not accidentally overwriting their changes than to have the system try to keep track of more stuff. Please clearly document your strategy in your submission.
• The application should sync down from the server automatically when the user opens an SR or BOE and sync up to the server whenever "saves" would normally happen in SRT.  If offline the sync doesn't happen until the user is online again and tries to open or save.

Open Source Library

If you need to use anything not already used in the current app, please get approval from us.

Technology Overview

This is a high level list, for detailed list please check the existing application.

• Java
• JSP
• H2 / Oracle 11.2
• Jetty / Tomcat 7

Documentation Provided

Register to download our existing code from challenge forum.

Final Submission Guidelines

Submission Deliverables

• Application Design Specification
• TCUML
• Assembly Specs (no components)
• ERD

Submission Guidelines

For each member, the final submission should be uploaded to the Online Review.