 |
Update Center 1.0 - High Level Overview
Key Features
- Support for multi-install and non-root install with multi-platform packaging.
- Extensible installation/uninstallation support for multiple module content types (archives, Java EE applications, Application Server addon installer jar files, Application Server addon configurator jar files).
- Client side desktop integration. Provides notification to user for new software or updates. Also, user can launch the update center client easily with one click.
- Update of Update Center - It is possible to send a new version of the update center client to the user. This is similar to how Firefox browser update experience.
- Scheduled update check - user is able to set how often update center client checks for new updates. For example, daily, weekly, never/manually. User can also manually initiate a check for updates.
- Centralized/clean configuration settings in an xml file. No magic property files.
- Modularized maven and ANT based build system. Also supports in-tree build for update center developers.
- Smart Update Center UI
- When user re-sizes the window, the Update Center clients remembers that for subsequent sessions.
- Identifies which components require a restart.
- Identifies the new software on the system.
- Identifies the date when a component was published.
- Shows real progress of download and installation with ability to cancel.
- Clear "details" window for available or installed software that allows each module author to provide overview, tech spec and support information in Html format. Hyperlinks are automatically opened in a browser.
- Related activities are be grouped clearly for easy navigation. For example, Available Software, Installed Software, Updates, Preferences. In each category, modules can also be grouped for intuitive presentation to end-users. For example, Java EE content, Portal related content, etc.
- User is able to save the preferences.
- Shows license before installation.
- Generic tokenization support during installation - It is possible to gather input from user during installation. For example when installing samples into Application Server user name and password etc.
- Usage stats are collected so that we can determine adoption of certain software hosted on the update center repository.
- Supports proxy - user is able to configure and save proxy server information to connect to the update center server. This also checks for system proxy.
- Supports local repository - User is able to change Update Center URL, add new Update Center, remove Update Center and change the query order. System update center URL(s) is not allowed to be removed.
- Supports express and selective installation and un-installation with dependency resolution.
- Secure - Repositories may require HTTPS access. Also, the hosted jars are signed by a CA to prevent man-in-the-middle attack.
- Fast - Uses multi-threaded environment to download software.
- Integrated with Akamai backend infrastructure. Also have a repository in China Education Network where chinese users can download our content for free without paying hefty fees to their service providers (more)
Build System
Uses Maven and ANT for the build infrastructure. The build allows to have top level modules. "bootstrap" module is the top-level build module consisting of building all or subset of the modules. Assuming that update center may have different modules, developer can select the option of "bootstrap" which would download the pre-built image and builds only subset of the modules. The build allows in-tree build to facilitate development. Each top level module has a NetBeans project. These projects can be used to build update center from the IDE environment. Refer to build instructions for more details.
Commons Package
Commons package has all common components of update center. api defines all the exposed APIs of the backend engine. All update center clients (UI, CLI) will use these interfaces. logging sub-package has the logging implementation. Support for log rotation, etc. are there. util sub-package has few utility classes.
Config Package
All update center configuration is defined in an xml file (DTD). Config package has implementation for all update center configuration. Implementation classes for managing catalog is also here.
Gui Package
Implementation for update center UI
Installer Package
Implementation for update center installer can go here. Currently, update center is bundled with GlassFish and Java EE SDK.
Repository Package
Update center repository (file layout) implementation.
Startup Package
Update center main class and desktop integration.
Tests Package
Update center unit tests.
Core Package
Update center backend implementation.
Download Manager :
download sub-package deals with downloading modules from repository. It can handle both SSL and non-SSL environment. Also, the server side jars can be signed by a CA. The implementation uses thread pool to execute the download requests in a multi-threaded environment.
Pausable Thread Pool Executor :
status sub-package is the base implementation for multi-threaded thread pool executor with progress object.
Security :
security sub-package deals with signed jar verification.
Config :
config sub-package deals with dynamic reconfiguration of user preferences.
Dependency :
dependency sub-package deals with module dependencies.
Install :
install sub-package deals with installation/uninstallation implementations for supported module types. Support for new module types can be easily added by implementing additional Installer classes in this package.
Module Life-Cycle and states :
Update Center client maintains two copies of the files (namely server.xml and local.xml) for every catalog. server.xml is exact replica of the catalog file obtained from the server. local.xml file will be initially empty. If the a state of module is changed locally, then local.xml will be updated. The possible states (property called Module-State) for a module are DOWNLOADED, INSTALLED, UNINSTALLED.
Downloader updates the local module state to be DOWNLOADED upon a successful module download.
Installer updates the local module state to be INSTALLED upon a successful installtion. If the installation fails, it leaves the module state to be DOWNLOADED. Installer updates the module state to be UNINSTALLED in case of successful un-installation. If the un-installation fails, it leaves the module state to be INSTALLED.
Question: Can there a module entry in local.xml with out Module-State?
Answer: No. There is always a module state in local.xml. DOWNLOADED -> INSTALLED -> UNINSTALLED in that order.
Scheduler can automatically download updates for an installed module. Inorder to maintain this state, we a properties called Update-State and Update-Version. The following describes the steps involved in installing an update. Once scheduler downloads an update for installed module, it adds and populates the Update-State and Update-Version properties. Once user selects an update for installation - now the original module's version is changed and the above two properties are removed.
Question: Can there a Update-State with out Update-Version entry in local.xml?
Answer: No. There is always a Update-Version for Update-State in local.xml, otherwise you would not know which version of update is DOWNLOADED or INSTALLED.
Question: Can there a Update-State equal to UNINSTALLED in local.xml?
Answer: No. Because as soon an update is INSTALLED, both Update-State with out Update-Version will be deleted and module version will be replaced with update's version. Are we planing to support rollback of update? In that case we can support this.
Even though user may have selected "automatically download updates". He may not be insterested in installing all those updates. Update Center maintains a flag called Is-Not-Interested to store this information. Let us say user has looked at these updates and not chose to install these updates, we add property called Is-Not-Interested and set its value to "true". The absense of this property means its value is false. Not interested modules can be cleaned up (remove the downloaded bits) after a month.
Question: Can there Is-Not-Interested be "true" with out Update-State and Update-Version entries in local.xml?
Answer: No. Is-Not-Interested is only useful for updates, not for Available modules (as of now).
The following are the only states that are possible in the system (as of now):
| Module-State | Update-State | Update-Version | Is-Not-Interested | Comments |
| DOWNLOADED | NOENTRY | NOENTRY | NOENTRY | Module is downloaded |
| INSTALLED | NOENTRY | NOENTRY | NOENTRY | Module is installed, should show in Installed Modules list. |
| UNINSTALLED | NOENTRY | NOENTRY | NOENTRY | Module is successfully uninstalled. |
| INSTALLED | DOWNLOADED | 1.6 | NOENTRY | Update is downloaded and user has not looked at it yet |
| INSTALLED | DOWNLOADED | 1.6 | true | Update is downloaded and user is not interested in this update |
Scheduler :
Scheduler is runs in the JDIC process and can inform JDIC code(tray) about available updates or downloaded updates or installed updates. It is implemented using a timer. When the timer times out it downloads the server catalog, figures out if there are any new updates. If there are non-zero new updates available, depending on the update preference Scheduler sends out MODULES_DOWNLOADED, MODULES_INSTALLED or MODULES_AVAILABLE event. JDIC code show a status message in the tray.
Question: What happens in case Scheduler gets an exception for example can not connect to Update Center Server?
Answer: An error message should appear both in the log files and in the tray information message.
Entry points into Update Center
./updatetool starts both GUI and Tray(along with Scheduler) in the same JVM. Even if the GUI is quit, Tray will be running. GUI can be restarted from the Tray's menu. If user is interested in only starting GUI, user can run ./updatetool GUI to start the GUI.
CLI and GUI check for updates according to update preference intervals that user has specified. They inform user, if there are new updates and ask the users to run updatetool to view the updates.
Call Home
Question: What kinds of information is sent back to the Update Center Server from the Update Center client?
Answer: As of now we send back installation ID, user's operating system, hardware type, locale, JDK version. From HTTP headers, we also know the IP address. See this document for more information.
|