Update Center Wiki: About

Home Index Changes Prefs Log in »

Overview

The Update Center project is delivering a cross-platform toolkit to enable applications to manage packaging and delivery of initial installation images, add-on components and updates using the network repository-based Image Packaging System (IPS)

from the OpenSolaris project.

Key Features

Multi-platform Packaging and Tooling	IPS-based packaging to deliver the same package format across a variety of OS platforms.
Network Repository-based Delivery of New and Updated Packages	Enabling publishing of packages and retrieval by client tools and applications
Installation Framework Integration	* Ability to use the OpenInstaller framework to assemble and install distributions that are installable from scratch. * Distros embed the Update Center client tools and include multi-platform application packages as payload.
Multiple Installations	* Formalization of how components making up an application are installed in a self-contained location on a system. * Ability for non-root or non-administrators to easily install, update and augment application installations. * Ability for multiple applications being installed in the same self-contained location on a system. e.g. A portal server installed in the same installation image as an underlying application server. * Solutions for dealing with desktop and OS integration challenges arising from multiple installation on the same system.
Single System Client Side Tooling	* GUI and CLI tools to manage installations and discover, download and apply updates and add-ons * SDK enabling applications to integrate these features in application-specific tools * Desktop task tray integration for notification of updates

Supporting Filesystem-based Applications

The primary objective of the Update Center project is to address the needs of both the projects that are producing applications and the developers and administrators that are managing and using applications that are installed directly to a filesystem. Examples of such applications include, but are not limited to:

Web and Web Proxy Servers
Application Servers
Directory and Directory Proxy Servers
Message Queuing Servers

Although these are examples of types of applications that are adopting Update Center features, the general purpose nature of the Update Center design should benefit a wide array of applications.

Higher Level Applications and Modules

Although applications and modules that are deployed to application runtimes or containers (e.g. Java EE modules, Ruby Gems, Portlets, JBI Service Engines, etc.) rather than directly to filesystem are not the primary focus of the Update Center project, projects may choose to wrap these higher level modules in the multi-platform package format, publish them via the package repositories and enable users to download the packages and updates to their systems.

An example of this scenario is the use of Update Center features to manage not only the installation and update of the GlassFish Application Server, but also the download, deployment and update of a Portlet container deployed to the GlassFish Application Server. Although the Portlet Container module is not installed directly to a filesystem, the Update Center extensions that recognize and supports WAR files as they apply to the GlassFish Application Server enables the Portlet container deployment to be managed through the Update Center features.

Staging Installations of Higher Level Applications and Modules

When applications and modules are eventually deployed to a container that is not managed via Update Center features, staged installations of these applications and modules on a filesystem can benefit from the use of the Update Center features. In these cases the Update Center features can be used to manage updates and additions to the staged installation images. Using the content of the images as a reference, developers and administrators can use application container-specific tools to deploy and update the applications and modules.

Using Update Center Features

Projects taking advantage of the Update Center features will typically follow these steps:

Package their runtimes and associated components in the portable package format,
Publish these packages and subsequent updates to them via network repositories that are accessed by client side package management tools
Assemble and deliver installable distributions that includes application content and, in some cases, the client side package management tools,

Developers and administrators using Update Center-enabled applications are able to:

Install applications that may optionally include the client side Update Center tools.
Use client side GUI and CLI tools to access repositories to determine availability of additions and updates applicable to their installed application.
Apply updates and additions directly from repositories and from local copies of packages.

Community leads and product managers are able to:

Leverage usage and popularity reports of client activity
Publish news and information concerning service and product offerings to users of the Update Center client GUI

Motivation

Although a series of middleware applications that are offered across a variety of OS platforms spurred the creation of the Update Center project and delivery of its initial feature set, the following problems are faced by a wide array of applications:

Problem / Opportunity	Examples
Complexities of Patching and Updating	Users: * Difficult to determine updates and additions for installed applications. * Difficult to obtain and apply updates and incremental additions. Projects: * Cost of delivering and maintaining updates for same application as supported on multiple OS platforms
OS Native Packaging Limitations	Users are not able to take advantage of multiple installation and non-administrator (or "non-root") install and management capabilities when using applications packages in OS native package formats. Developers and administrators often need to install and manage multiple installations of the same and different versions of an application on the same OS instance.
OS Distro-specific Repositories	OS distribution-specific repositories are not always available for projects to use. For example, on Windows there is no general purpose update and package delivery repository for projects to leverage. Same is true on Mac OS X. On Linux distros the situation is a bit better in that a project may either work with the disto owners to package the project's packages into the distro repositories or the project can establish its own repositories.
Limitations of Tar- and Zip-based Installations	Although tar- and zip-based application distributions address the non-root and multi-install limitations of many native packaging formats, these unpackaged formats come with their own limitations. Users: * No built-in means of applying updates and incremental additions Projects: * No easy means of sharing components in packaged form. * No easy means of delivering updated packages.
Relationship with Developers and Administrators	A general purpose update GUI can leverage desktop users' eyeballs and interactions with community and commercial repositories to promote community interests and to offer products and services.
Promoting Partner Contributions	An open repository approach helps projects and vendors publish and share packages such that users can easily be made aware of and install new and updates offerings.
Different implementations for open source and commercial applications	A common, flexible packaging systems and repository delivery approach can enable projects to deliver a single binary format for both their open source project binary distros and their commercial counterparts.