Return to parent thread

UpSync Tool Development and Deployment

The DfR UpSync Tool is a software tool that performs the work of transferring files from a user's local system to DuraCloud. This tool will be installed and run by the users of DfR, and as such, should be simple to install, configure, and run.

UI Development Options

Selected Option

UI created as a web application

  • Server side code would be in Java, client side code would be HTML/JSP/JavaScript/CSS
  • Benefits:
    • Can create beautiful-looking UIs
    • Dev team has existing expertise in web application development
  • Drawbacks:
    • User would need manage the server (starting and stopping as necessary) and connect to the UI via a browser
      • Shortcuts can be created to make these steps easier, but the two steps will always be necessary

Primary Reasons for this selection:

  1. In order to maintain the synchronization in an on-going fashion, a daemon of some kind is required. Using a deployed web application works well in filling this need
  2. The web application can be hosted on one machine and accessed from multiple machines simultaneously. In lab environments or when using intra-net style networks, this could be a significant advantage.
  3. There is greater flexibility in terms of how this application could be changed/updated in the future to have a tighter integration with externally hosted portions of DfR
  4. The development team is already skilled at web application development.
  5. Users are generally already familiar with working within a web browser.

Discarded Options

UI created as an application to be run directly on a JVM

  • Can be written in a variety of languages (Java, Ruby, Python, etc) but primary UI technology is Java Swing
  • Benefits:
    • Simple, proven strategy for deploying client-side UIs
    • Deployment consists of simply executing a single class, which starts up the UI and manages all sync processing
  • Drawbacks:
    • Complex UIs can take time to develop.
      • Tools and frameworks are available to simplify the process. Most Java IDEs have built-in Swing support, there are also tools like WindowBuilder and JGoodies and frameworks like MonkeyBars and LimeLight.
    • Existing developer expertise is likely not current
    • Swing UIs generally tend to look utilitarian

UI created using commercial tools for local deployment

  • Adobe Air
    • No linux support
  • Google Gears

Deployment

Options

Deploy as an executable jar
  • Can be run anywhere a JRE is available
  • For Webapp, execute using embedded server
    • Running Jetty server in embedded mode is well documented
    • Web browser is used to access locally running server application

Issues:

  • Requires a 1.6+ java JRE to be pre-installed
  • Users often don't know what to do with a Jar
Solution 1: Use IzPack

Issues:

  • Still requires a 1.6+ java JRE to be pre-installed
Solution 2: Create a platform-specific installer

Backup strategy, for platforms where an installer is not available: Executable Jar and instructions

Selected Option

Initially, and as a backup strategy, deploy as an executable JAR file
Final solution: Create platform-specific installers (Solution 2 above)

  • Use InstallBuilder to build installers for all platforms with a single configuration. Configure this as part of the build process.
  • Have each installer set up the application to run as a daemon (Linux, Mac) or service (Windows) which is automatically started and stopped with the machine

User Experience

These is the expected user interaction with the UpSync installer/application in the final DfR revision.

Installation

  • User downloads installer
  • User executes installer
    • Installer places executable in an installation directory
    • Installer creates a service (windows) or init script (linux) to auto start the application on machine boot
    • Installer drops a pre-created shortcut on the desktop which will bring up a web browser to the proper url
    • Installer starts the application

Runtime

  • UpSync Server is started on installation and system startup (see above)
  • User selects the web shortcut on the desktop and a web browser opens to show the DuraCloud UpSync web application
  • User sets configuration via the web UI. This information is stored on the local file system and retrieved on restart
  • User closes the browser when their settings have been successfully entered
  • The UpSync server continues to run in the background, transferring files base on the configured data and schedule

Development Notes

  • The startup process for the webapp needs to manage:
    1. Discovering any existing configuration information
    2. Restarting the sync process based on the configuration

Return to parent thread

  • No labels