U.S. patent application number 12/127985 was filed with the patent office on 2009-06-04 for interpreted multiple product installation.
This patent application is currently assigned to BEA SYSTEMS, INC.. Invention is credited to David Felts.
Application Number | 20090144727 12/127985 |
Document ID | / |
Family ID | 40677099 |
Filed Date | 2009-06-04 |
United States Patent
Application |
20090144727 |
Kind Code |
A1 |
Felts; David |
June 4, 2009 |
INTERPRETED MULTIPLE PRODUCT INSTALLATION
Abstract
An installer can do a combined installation of multiple software
products. The installer can do a combined pre-install phase, a
combined install phase, and a combined post-install phase for the
multiple software products.
Inventors: |
Felts; David; (Denville,
NJ) |
Correspondence
Address: |
Fliesler Meyer LLP
650 California Street, 14th Floor
San Francisco
CA
94108
US
|
Assignee: |
BEA SYSTEMS, INC.
San Jose
CA
|
Family ID: |
40677099 |
Appl. No.: |
12/127985 |
Filed: |
May 28, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60992267 |
Dec 4, 2007 |
|
|
|
Current U.S.
Class: |
717/175 |
Current CPC
Class: |
G06F 8/60 20130101 |
Class at
Publication: |
717/175 |
International
Class: |
G06F 9/445 20060101
G06F009/445 |
Claims
1. An installer adapted to do a combined installation of multiple
software products, the installer adapted to do a combined
pre-install phase, a combined install phase, and a combined
post-install phase for the multiple software products.
2. The installer of claim 1, wherein the software products are each
made of components.
3. The installer of claim 1, wherein multiple software products are
combined using an alias.
4. The installer of claim 1, wherein the installer provides a
single pre-install presentation to a user.
5. The installer of claim 4, wherein the preinstall presentation
obtains user pre-install input at a single time.
6. An installer adapted to provide a single pre-install
presentation to a user for multiple software products, the
pre-install presentation obtaining user pre-install input at a
single time.
7. The installer of claim 6, wherein the software products are each
made of components.
8. The installer of claim 6, wherein the multiple products are
defined by an alias.
9. The installer of claim 6, wherein the installer provides a
combined pre-install phase, combined install phase and a combined
post-install phase for the multiple products.
10. A computer readable storage medium including: installer code to
do combined installation of multiple software products, the
installer code doing a combined pre-install phase, a combined
install phase, and a combined post-install phase for the multiple
products.
11. The computer readable storage medium of claim 10, wherein the
software products are each made of components.
12. The computer readable storage medium of claim 10, wherein
multiple software products are combined using an alias.
13. The computer readable storage medium of claim 10, wherein the
installer provides a single pre-install presentation to a user.
14. The computer readable storage medium of claim 10, wherein the
preinstall presentation obtains user pre-install input at a single
time.
15. A computer readable storage medium including: installer code to
provide a single pre-install presentation to a user for multiple
software products, the pre-install presentation obtaining user
pre-install input at a single time.
16. The computer readable storage medium of claim 15, wherein the
software products are each made of components.
17. The computer readable storage medium of claim 15, wherein
multiple software products are combined using an alias.
18. The computer readable storage medium of claim 15, wherein the
installer provides a combined pre-install phase, combined install
phase and a combined post-install phase for the multiple products.
Description
CLAIM OF PRIORITY
[0001] This application claims priority to U.S. Provisional
Application No. 60/992,267 entitled "PATCH ATTACHMENT FACILITY" by
David Felts, filed Dec. 4, 2007, which is hereby incorporated by
reference [Atty. Docket No. BEAS-02252US0].
BACKGROUND
[0002] Installers are used to install software programs onto
computer. In order to use software programs, the program components
are typically unpacked and the relevant information placed on the
computer, taking account of variations between computers, and
customized settings input by the user.
BRIEF DESCRIPTION OF THE FIGURES
[0003] FIG. 1 is a diagram showing the use of metadata so that an
installer can automatically install patches to a software
product.
[0004] FIG. 2 is a diagram that shows an installer for a combined
installation of multiple software products.
[0005] FIG. 3 is a diagram that shows the organization of the
software product using feature sets.
[0006] FIGS. 4A-4B illustrate product and feature metadata of one
embodiment.
[0007] FIGS. 5A-5C illustrate product to component mapping,
component to feature mapping, and feature to module mapping of one
exemplary embodiment.
[0008] FIG. 6 illustrates an exemplary provisioning
architecture.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
[0009] In one embodiment, the patch management system 102 is used
to load patches 104 onto software 106. One way to do this is to use
a graphical user interface (GUI) 103 to select the patches to load.
The patch management system can keep track of the patches as well
as the dependencies of the patches with the components of the
software 106. Details of one embodiment of a patch management
system are described in the patent application entitled "PATCH
MANAGEMENT SYSTEM", by David Felts, filed Oct. 6, 2006, U.S. patent
application Ser. No. 11/539,261 [Attorney docket number
BEAS-01780US1] incorporated herein by reference.
[0010] It is not always desirable for a user to be required to
control the loading of the patches through GUI 103. In some cases,
it is desirable that the software be installed with the patches
automatically loaded onto the system.
[0011] One embodiment of the present invention is a patch
management system 102 to load patches 104 to a software program
106. An installer 108 can be used to install components 109 of the
software program 106. The installer 102 can be adapted to interpret
metadata 110 to instruct the patch management system 102 to
automatically load patches 104 to the software program 106. The
software components and patches can be loaded in a combined
operation.
[0012] The installer 108 can use the metadata 110 to determine how
to instruct the patch management system to load the patches. In one
embodiment, the patch management system 102 can receive the same
set of control instructions from installer 108 as from the GUI 103.
This can ensure that there is no difference in the patch loading
behavior whether it is controlled by the GUI 103 or installer
108.
[0013] The installer 108 and the patch management system 102 can
update version information based on loaded software components and
patches. For example, one field of a version number can indicate
any loaded patches. This can allow support operations to understand
what is loaded on the system 105.
[0014] An install repository 120 can indicate what software
components are stored on a system and be used to keep track of
component dependence. The install registry can get information from
a global product registry 122 that can indicate all of the software
component dependencies of an entire software product line.
Dependencies can indicate what components need to be loaded
together as well as what components conflict. In one embodiment, a
patch catalog 124 is analogous to the global product registry and
indicates all of the patches as well as the patches
dependencies.
[0015] The metadata 110 can be used to determine the patches to
place in an install package 128. The install package 128 can be
used by the installer and the patch management system 102 to load
the patches.
[0016] The metadata can be a XML file. The XML file can indicate
what patches to load in what order.
[0017] In one embodiment, the installer 108 checks the metadata 110
and the install registry 120 to determine what patches 126, and
additionally what components 109, that need to be loaded. The
components 109 can be loaded by the installer and the installer 108
can instruct the patch management system 102 to load the
patches.
[0018] In the example of FIG. 2, the installer 202 uses the install
package 210 to load the multiple software products 204, 206 and 208
onto system 212. The install package can include alias information
indicating the multiple software products. The installer can
determine from the alias information that a combined installation
is to be done.
[0019] The installer 202 can check an install registry 214 before
doing the installation. The install registry 214 can indicate what
is installed on system 212. The installer 202 can determine how to
install the multiple software products using the install registry
214. For example, the installer can check for and deal with any
dependencies in the software product to be loaded.
[0020] In one example, if a software product is already installed
on system 212, the installer can skip installing that software
product in the combined installation.
[0021] It is desirable to have an installer 202 that can install
multiple software products in a combined operation.
[0022] In one embodiment, installer 202 does a combined
installation of multiple software products 204, 206 and 208. The
installer 202 can do a combined pre-install phase, a combined
install phase, and a combined post-install phase for the multiple
software products 204, 206 and 208.
[0023] The combined pre-install phase can be a phase in which the
user input for the multiple products can be obtained. For example,
configuration information for the multiple software products can be
obtained from the user at a single time.
[0024] The post-install can include the display of an indication of
how the install went. For example, the post-install can be a
display that the combined install was successful.
[0025] In one embodiment, the multiple products can be hidden
behind an alias that is used for marketing. The user need not even
be aware of the identity of the different software products.
[0026] In one embodiment, metadata identifying the multiple
software products can be provided to the installer. This can be
alias metadata that points to the multiple software products.
[0027] In one embodiment, the loading of the software products can
include the automatic loading of patches using the system shown in
FIG. 1.
[0028] The software products can each be made of components. The
multiple software products can be combined using an alias.
[0029] A software product 312 can comprise multiple components 314
and 316. At least one component 314 can comprise multiple feature
sets 302 and 304. The feature sets can each define multiple OSGi
bundles. The installation can include installing the OSGi bundles
as indicated by the feature sets. The runtime can also include
loading the OSGi bundles as indicated by the feature sets.
[0030] An installer can install the OSGi bundles as indicated by
the feature sets.
[0031] Multiple products 320 and 312 can form a composite product
322. The composite product 322 can be defined by an alias 324.
[0032] The software product 312 can be patched by switching OSGi
bundles. For example, each bundle affected by a patch can be
replaced by a new bundle.
[0033] An installer can use an alias 324 to indicate a combined
software program 322. The combined program 322 can include multiple
software products 320 and 312, the software products 320 and 312,
each being independently runnable. The alias 324 can be used by the
installer system to install the multiple software products
automatically.
[0034] The software product 312 comprises components 314 and 316.
The components 312 and 314 can include feature sets 302 and 304.
The feature sets 302 and 304 can include modules, such as OSGi
bundles 306, 308 and 310.
Exemplary Non-Limiting Embodiment
[0035] An exemplary non-limiting example showing one system using
concepts of the present invention is described below.
[0036] A "Global Product Registry" (GPR) model can define
company-wide products, product versions, components and maintenance
levels, along with related attributes governing dependencies and
distribution aspects. A File Definition model can contain the
blueprint for file and directory installation, mapping each file in
the installer payload to its final destination on the customer's
system. Many attributes, including rules and filters, can govern
the mechanics of file installation. An XML file can embody the File
Definition model and a separate file can exist for each product.
The File Definition model can be an important part of the extended
Product Provisioning Model. The File Definition model is critical
to a change required to support shared modules.
[0037] Software companies have a growing need for greater business
agility to opportunistically create bundled software distribution
packages that map to Stock Keeping Units (SKU's) consisting of new
permutations of available products.
[0038] Marketing and executive management require the ability to
create arbitrary external product brand names and versions, while
standard product provisioning operations require normalized
internal product names and versions. Structured product
provisioning data can preserve the ability to upgrade and patch
products consistently, enable customer provisioning automation, and
maintain reasonable supportability of the products.
[0039] Software companys' current architectural directions dictate
modularity and modular product distributions. Product distributions
can now contain modules, also known as bundles in OSGi parlance.
Modules are very granular. Consequently modules can require (1) a
higher level intuitive semantic for purpose of dependency
declaration between function module groups as well as (2) a
simplified method of starting OSGi-based runtime applications.
[0040] The Core Engine Launcher can require an interface to return
module lists based on requests for published feature versions. The
interface can resolve dependencies and order modules appropriately
by start level. The model used by the interface can be consistent
with that used by installation to ensure that runtime dependencies
are backed by installed media.
[0041] FIG. 4A shows a diagram of the metadata associated with a
product of one embodiment. Product Alias need not be part of the
hierarchical product tree. A product alias can refer to one or more
products, but this need not imply parentage. In one embodiment, the
official root of the hierarchical product model begins with a
product element.
[0042] FIG. 4B shows a diagram that shows the relation of Feature
Sets and Modules. The Feature Model can be joined to components in
the Product Model via feature-refs (feature references). Think of
components as being composed of features, rather than dependent on
them, i.e. features depend on features, but do not depend on any
entity in the product model. This provides loose coupling between
the Product Model and Feature Model, mapping runtime and install
elements.
[0043] Provisioning code can depend on a product registry file. The
product registry file can be located in a Home folder. The registry
can contain information about products and the environment upon
which products depend, e.g. specification of necessary virtual
machines. Many values and related semantics can correspond to
values in the GPR however the registry is based on a separate
model. This can be reflected in processing prevalent throughout the
install framework. One embodiment of the new design calls for
convergence of the GPR and registry models, adding critical
information to the Home registry and simplifying processing
algorithms in the install framework. This can address a long
standing business requirement to enforce cross-product dependencies
during un-installation. Further, this can facilitate an interface
to create a list of modules along with normalized start levels
based on activation requests for products, components or specific
features. References to the GPR in this document are synonymous
with references to the Product Model.
[0044] A Product Alias element can be added to the Product
Provisioning Model, referencing one or more products. This can
provide a loose coupling between the external market-oriented
product name and version and the internal product names and
versions. The internal product names and versions can be captured
in the registry and used for all code-based decisions during
installation and other provisioning related activities.
[0045] A concrete Feature Model can be added to the Product
Provisioning Model. A feature can be referenced by components in
the Product Model and serves as a bridge linking install and
runtime aspects of an artifact or module. Features can be versioned
and contain a group of versioned modules.
[0046] Modules can be grouped under features. Modules can be
designated as "shared". Shared modules need not belong to any
specific product but rather can be targeted for distribution with
two or more products requiring the same unit of functionality.
[0047] Product aliases can allow marketing flexibility without
impact to normalized, consistent methods of identifying software
artifacts for purpose of installation, un-installation, upgrade and
patch. The product alias name and version may be unreliable for
purpose of code and tool based detection and automation, i.e. the
versioning scheme may not follow a rational, uniform syntax or be
predictable with a consistent, monotonic, incrementing of the
version number.
[0048] A product alias enables creation of a product suite from a
group of products. Moreover this layer of abstraction removes the
need to modify product names and versions with each new suite
permutation. This facilitates a consistent semantic for customer
use, e.g. when contacting support or interfacing with a Patch
Management system.
[0049] Product aliases can be defined in the GPR. The GPR can
contain a separate section for each product alias, which in turn
contains references for each included product.
[0050] The term product defines the lowest level of granularity for
a complete software offering targeted for customer consumption.
Note that more than one SKU may be defined for a given product
based on product features enabled and usage characteristics of the
features, e.g. constraints placed on features to restrict usage to
a development scenario.
[0051] The product element can serve as a container for a group of
components. In order to effectively deliver a product for customer
consumption, components can be grouped and referred to by an
immutable name and version. This is done in order to develop and
release product according to a standard lifecycle methodology.
Orderly and automated installation, un-installation, upgrade and
patching of products also uses a normalized naming and versioning
scheme. Moreover, this facilitates a consistent interface for
customers and effective customer support.
[0052] A product may contain a mixture of components used
exclusively by this product as well as components containing
"shared modules" that can be used by multiple products.
[0053] Products can be defined in the GPR. The GPR can contain a
separate section for each version of a given product, including
service/maintenance pack versions.
[0054] The components can define a functionally specific group of
software executables and artifacts designed to provide customized
product installation options. Installation options enable various
customer use cases. A product can contain optional features that
are appropriate only for specific use cases. Providing the ability
to optionally install enables a reduction in the footprint on disk
and may reduce the download footprint. Optional installation may
also facilitate a development versus production product image. In
the case of a production installation, it may be necessary to avoid
installation of certain components whose presence represents a
security vulnerability according to local policy.
[0055] Components can define dependencies on other components,
including components belonging to different products. Multiple
dependencies can be expressed using a logical "and" or "or"
semantic. Regular expressions can also be supported.
[0056] Components can also contain feature references. Features in
turn can define dependencies, which are inherited by the parent
component. Based on dependencies, components may be automatically
selected or de-selected in installation and un-installation
scenarios. Moreover, installation and un-installation errors or
alerts can be generated when dependencies span products. Features
are fully defined in the following section. Components can be
defined in the GPR.
[0057] A feature can define a container element for modules as well
as inter-feature dependencies. Features can be versioned as they
are standalone entities, not subject to any higher level element. A
particular feature version can contain one to many module versions
that are functionally related and certified as compatible. Features
can be the primary entity used to identify modules to start in an
OSGi environment. Features can also be the primary vehicle used to
distribute certified software combinations internally for consumers
of the Core Engine.
[0058] Feature Definitions can adhere to a schema-based model
allowing definition of constituent modules and feature
dependencies. Each module entry can contain a module name, optional
start level and shared module indicator. When the Core Engine
launcher processes module entries, the module start level
determines the sequence of module activation. The model also
permits declaration of dependency elements capturing relationships
between feature versions.
[0059] Several files can support feature definition and
dependencies. An XML Feature Definition file embodies the Feature
Model. A separate file can exist for each feature version. In one
embodiment, it can adhere to the naming convention
<featurename>.sub.--<4positionversion>.xml. A jar file
can be automatically generated during an installer build for each
feature version. The jar file can consist solely of a manifest with
a classpath entry containing all modules listed in the Feature
Definition file. Non-OSGi based runtime systems can use the jar
files to systematically create the appropriate classpath. The jar
can adhere to the naming convention
<featurename>.sub.--<4positionversion>.jar. Lastly,
optional feature-set jars can hold manifest classpath references to
a collection of related feature jars. A feature-set jar can adhere
to the naming convention
<featurename>.feature.set.sub.--<4positionversion>.jar.
[0060] Feature dependencies can define mandatory relationships
between groups of software executables and artifacts. Multiple
dependencies can be expressed using a logical "and" or "or"
semantic. Regular expressions need not be required for features, as
dependencies can be very direct. In one embodiment by contrast,
regular expressions can be supported for the component element, as
both products and components are expressed in dependency
relationships associated with components.
[0061] Logical "not" dependencies can enable handling of mutual
exclusion use cases. A Feature Exclusion model can capture these
exclusions. Separate modeling of exclusions can avoid heuristics
and performance problems inherent with inclusion of this dependency
type in the base dependency graph. Exclusions can be processed
after completion of base graph processing.
[0062] Feature dependencies can be independent of OSGI-based module
dependencies, which can be highly code dependent from a syntactical
perspective. Feature dependencies can relate to a logical
dependency, e.g. one module writes a particular configuration file
or entry in a configuration file that is required by another
module. In this example, OSGI-based semantics may not capture the
dependency.
[0063] A strong relationship can exist between runtime dependencies
and installation artifacts and this can manifest itself in the
relationship between feature and component dependencies.
Installation dependencies can be a derivative of runtime
requirements. The installer build process can automatically
percolate Feature Definition dependencies to relevant component
entries in the Product Model. Component dependencies can drive
installation file processing.
[0064] Features can be defined in a separate model. Feature
references can be coded under the component element in the GPR
provide linkage between the Product model and Feature Model.
Components can be composed of features.
[0065] A module can be an OSGi-compliant file or other archive that
can be directly loaded and used. For example, a module may be an
OSGi bundle, a jar intended for use on the classpath of a
Java-based runtime system or a WLS shared library. A module can
contain an embedded version in its file name. Each module can
provide very granular functionality.
[0066] A shared module can provide common functionality targeted
for use by two or more products. Shared modules can install under
the Home directory, rather than a specific product directory. The
installer can track usage for each shared module via a reference
count, since multiple products can depend on the same module.
Reference counting can prevent premature un-installation of shared
modules required by an active, installed product. A separate file
can contain reference counts for all shared modules installed into
a given Home directory. This file can reside either under the Home
directory or a well-known sub-directory of the Home directory. A
separate file tracking all shared modules with associated reference
counts, rather than storing associated data in an existing
meta-data file can allow for efficient access. In theory, reference
counts can be tracked in the Feature Definition file, but this can
require traversal of all Feature Definition files during
un-installation processing.
[0067] The GPR can contain definitions for supported Java Virtual
Machine (JVM) versions per product release. Each JVM entry can
contain a definition of supported OS/architecture platforms.
[0068] The JVM definition can be a peer to component, rather than
appearing as a component. There are several factors that drive this
distinction. A separate versioning system can apply for the JVM and
version upgrades and patches are not managed via the same mechanism
as other product artifacts. Some products include multiple JDK's,
including JDK's supplied by other vendors. Lastly, JDK/JRE
installation can require different handling from a technical
standpoint, where native compression routines are required to
preserve symbolic links for some platform. Considering these
factors, the JVM/JDK/JRE need not be consistent with other product
artifacts and as such, a separate installation paradigm
applies.
[0069] Additional JVM/JDK/JRE information can be captured in a
separate model outside of the GPR, embodied in a global XML file
(jvm.xml). The model can include detailed version and vendor
information, along with meta-data used to construct the JVM from
constituent parts, e.g. tools versus the JVM library.
[0070] FIG. 5A shows an exemplary product to component mapping.
[0071] FIG. 5B shows an exemplary component to feature mapping.
[0072] FIG. 5C shows an exemplary feature to module modeling.
[0073] FIG. 6 shows an exemplary Product Provisioning Architecture.
The implementation of the Global Product Registry (GPR) and Home
Registry File include: [0074] Create a new registry. [0075] Provide
synchronization routines to preserve old registry for prior
installers. [0076] Modify internal data structures and API's
throughout the installation framework and public interfaces
exposing related metadata. [0077] Include review of Maintenance
Pack Installer to ensure preservation of current conditional
installation and dependency enforcement processing, and appropriate
handling of shared modules. [0078] Modify internal data structures
and API's throughout the Patch Management System framework. Review
processing associated with command line usage to ensure semantics
are preserved. [0079] Modify internal data structures and API's
throughout the Configuration Wizard framework, specifically
concentrating on component selection. A mapping to rationalize the
current and new Product Provisioning Models can be required. [0080]
Encrypt registry, providing accessors and mutators. [0081] Business
rationale: Filter sensitive data and protect from manipulation and
external dependencies.
[0082] Implementation of the Product Alias can: [0083] Change
installer displays to reflect the high-level alias for customer
consumption. [0084] Change the installer component selection panel
to display product/component hierarchies rather than
component/sub-component hierarchies. [0085] Change the installer
product directory selection panel to allow specification of
multiple product directories. Allow for a default product directory
to apply across two or more products, based on optional attributes
in the GPR. Note that this can require tight coordination across
teams to ensure namespace protection of artifacts not containing an
embedded version in the name of the associated directory or
archives [0086] Change product/component selection displays in
Smart Update (including SP/MP and Patch Management sections).
[0087] Change product/component selection displays in the CCE Patch
Management tool.
[0088] Feature and Dependency Processing can be implemented by:
[0089] Modify dependency graph and provide new graph traversal and
helper routines.
[0090] Shared Modules can be implemented by: [0091] Provide
reference counting. [0092] Institute File Definition model changes
and install build routines.
[0093] Maintenance Pack Installer can be implemented by: [0094]
Review installer to ensure preservation of existing functionality
with the new Product Provisioning Model.
[0095] The Core Engine can specify the syntax and semantic for
shared module versions (OSGi bundles). In one embodiment, the
paraphrased version syntax can be defined as [major-release].
[minor-release]. [maintenance-pack]. [sequential-patch-number].
[0096] The Patch Management System can provide support for multiple
patch types/methods relevant to module patching. Business and
technical use cases along with policy can drive selection of the
most appropriate method. Complicating the picture, module usage by
the Core Engine can differ significantly from usage by WebLogic
Server and dependent products. Increasing the complexity even
further, WebLogic Server can also support library modules, which
have special requirements for naming and versioning as described in
the Patch Management--Shared Archives specification.
[0097] The Patch Management System can generate a random and unique
Patch ID for each created patch. The random nature of the ID can
support either a "one-off" or rolling patch model. Rolling patch
semantics can be communicated to the customer via the Patch
Description field and further clarified by using UI characteristics
of the Smart Update Tool that depicts Critical versus Optional
patch groupings.
[0098] For shared modules consumed by the Core Engine, a complete
replacement patch type can be used. In one embodiment, the module
name can change in the fourth (patch) position of the embedded
version string. Although classified as a replacement patch type,
from a file system perspective, this can involve installing a new
module. This patch method can hold the greatest negative impact for
patch repository footprint, customer system footprint, and any
operation requiring transport of the patch or patchsets containing
multiple modules. Further it may require additional manual handling
by the customer to load the new patch module for runtime usage.
[0099] A second viable model for shared module patching involves
replacement patches via injection, also supported by the Patch
Management system. This method addresses the footprint issue and
provides support for a "one-off" model. However, this would
preclude use of signed modules and it appears to force global
uptake of patches by all products dependent on the target module.
The latter point may be addressable via custom profiles.
[0100] The Patch Management System can provide support for other
patch installation patch types, e.g. classpath patching, path and
libpath patching, but these are not currently relevant to the
module discussion. The diversity of patch types can provide
flexibility for several different support models, e.g. one-off
patches, full rolling patches and rolling patches for a particular
class of patches and are mentioned here for completeness.
[0101] A Feature/Module Runtime Registry API can provide location
independent access to product module registries and the means to
start groups of modules using customer-friendly semantics. The
initial consumer of the API can be the Core Engine Launcher, but
the interface and implementation can be generic, allowing potential
use by any engine or server predicating system start on
modules.
[0102] The API can provide the following functions: [0103] Returns
launcher object [0104] Artifacts constituting the launcher use the
same feature and version paradigm applicable to common modules,
facilitating a normalized interface. [0105] The interface returns
the highest version of the launcher [0106] Returns module list
[0107] The module list contains module objects providing detail
about modules, e.g. location, based on the feature list supplied in
the request [0108] Specific feature versions are not required as
the API detects multiple versions of a specific feature, returning
an exception in this case. [0109] The list is ordered based on
normalized start level. [0110] Returns install directories
associated with started products [0111] Returns artifacts available
for certain data categories, e.g. configuration data, for started
products [0112] Artifact categories are associated with specific
locations in product directories. Categories and associated
locations are loosely coupled via a property file in a well-known
location relative to a product directory. Product teams can
manipulate the properties file, providing configuration
flexibility. [0113] Returns Home directory
[0114] The API can provide a factory method returning a
configuration object. The configuration object can provide a method
that returns a module list based on supplied parameters including
product, component and features. The high level parameters, e.g.
features, used in the interface insulate customers and internal
developers from having to understand and specify the full set of
modules upon which they are dependent. Product teams with intimate
knowledge of their modules can group these together under intuitive
features. As described earlier, components can be composed of, i.e.
map features. Components in turn belong to products in the Product
Provisioning Model hierarchy.
[0115] The API can normalize module start levels across products.
Module start levels can be defined by each development team can be
relative within a product. Creation of static module lists with
start levels normalized across all product permutations can be
extremely complex, error prone and require constant maintenance.
Instead, this API can use a feature dependency graph to create a
global module start order spanning products.
[0116] The archive can contain implementation classes for the API
on the primordial classpath, i.e. the same classpath used to start
the microkernel and launcher. This allows bootstrap of the launcher
and ensures knowledge of the Home directory location. The Home
directory can be the root of all critical bootstrap meta-data.
[0117] The feature dependency graph used by this exemplary API can
support "and" and supports "or", but need not support "not".
Enforcement of mutual exclusivity can be achieved by a separate
exclusion map, i.e. the Feature Exclusion Model. This can be
applied after graph operations and never changes the graph;
heuristic conditions can be surfaced as exceptions. In one example,
only a single version of a given feature is allowed in a list of
features to start.
[0118] Software can incorporate a modular approach to developing
and distributing software. Modules can be shared by multiple
products. Further, the paradigm for loading modules into runtime
containers differs between the software products.
[0119] Software customers can be familiar with a style of patching
referred to as "classpath" patching. Classpath patching enables
very granular patching of artifacts with a corresponding small
download footprint.
[0120] The Core Engine can be based on a framework for managing
applications specified by an open standards organization known as
the Open Services Gateway initiative (OSGi). This framework need
not support deterministic loading of duplicate classes spread
across multiple jars/modules. Consequently, in one embodiment, Core
Engine patches are delivered via a complete module. The usability
for consumption of patches in a Core Engine environment can
approximate that for other products and patch types, with
reasonable latitude provided for intrinsic technical
characteristics of OSGi-based module launching.
[0121] The patch creation process can integrate intuitively with
the existing tools and systems. Module patching need not require
duplication of effort to accommodate the two runtime methods
described above.
[0122] A "module" patch type can be used in the Patch Management
System to accommodate patching of entities referred to as modules
or bundles.
[0123] The source artifact for inclusion in the patch can be a
module or modules. Modules can be selected from the file system via
a file system tree view in a similar fashion to selection of
archives for patches of the type "classpath". The selected archives
can be then targeted to module entries. Each module entry can
consist of a module name with an embedded version in the name.
Targeting can involve a user interface that enables association of
the source archive with a target module name.
[0124] In one embodiment, when creating a module patch, two options
can be presented to the software design engineer for selection in
the user interface. In one example, at least one of the options
must be selected and both can be selected. The options are: [0125]
"Load via classpath" [0126] "Load via OSGi"
[0127] Similar to classpath patches, only changed artifacts need be
included in the patch archives All other aspects of patch creation
align with processing for other existing patch types.
[0128] The patch payload for module patches can closely mirror that
of classpath patches. Installation of module patches for classpath
loading can be similarly indistinguishable from pure classpath
patches. However, a module patch can differ in its ability to
create a patch for consumption by an OSGi launcher.
[0129] Artifacts can be included in the patch classpath using the
existing patch management system mechanism applicable for
classpath-based patching. This can provide continuity in processing
for existing customers.
[0130] OSGi does not have the ability to deterministically load the
same class from multiple jars/modules. Instead, a complete module
containing patched classes can be provided. The following steps can
create a complete module on the target system using essentially the
same patch payload created for classpath patches. [0131] 1.
Duplicate the target module residing on the customer's system,
placing this in the default patch profile, or patch profile
explicitly selected by the customer. Note that the process of
duplication does not result in a file name change. This ensures
that no module references require modification. The use of patch
profiles and Patch Management System tracking functions can
eliminate the need to modify module name or embedded version.
[0132] 2. Inject artifacts (classes) from the downloaded patch
payload into the duplicated module. [0133] 3. Track artifacts
injected into the patched module by populating entries in the patch
backup definition file. This file is located in the patch directory
specific to the product/release/maintenance pack level targeted by
the patch. Track the sequence of patches applied to the module. The
logic supporting sequence tracking must handle the use case where a
customer performs un-install of a patch that is not the latest
patch applied. For example, given 5 patches applied to a specific
module, the customer performs un-install on the second of the 5
patches applied from a chronological perspective. Note that this
approach doesn't require physical backup of the artifacts in the
patched module, as the injected artifacts still reside in the patch
directory. The control information residing in the patch backup
definition file together with the ability to re-inject patches into
the module supports all known un-install scenarios. [0134] 4.
Update the patch module list under the "patch" sub-directory of the
common modules directory located in the Home directory. This module
list contains entries for each patched module and identifies the
product/release/maintenance pack association for the module, along
with the patch profile under which the module resides.
[0135] Module patches can be applied to custom profiles, consistent
with other patch types.
[0136] Runtime processing of module patches can differ depending on
the system used to load modules. Similar to patch installation,
runtime processing of module patches loaded via the classpath can
mirror processing of typical classpath patches. The customer should
not perceive a difference unless they closely inspect internal
meta-data.
[0137] Modules delivered via the Patch Management System and loaded
using the classpath function identically to classpath jars
delivered under the current version of the Patch Management System.
Custom profile handling and processing can be similarly
consistent.
[0138] Different processing applies to modules delivered via the
Patch Management System and loaded by the Core Engine OSGi-based
Launcher. The Launcher can derive a list of modules to start by
processing feature requests using a Feature Registry API. This is
the Launcher module start list. For context, feature sets (also
referred to as features) are versioned sets of functionally related
modules that can express dependencies on other features. Features
can also have product affinities.
[0139] After compiling a list of modules and prior to returning
this to the Launcher, the Feature Registry API can compare the
patch module list, created during patch installation, to the
Launcher module start list. If a module matches on version and
product association, the entry from the patch module list can
replace the corresponding entry in the Launcher module start list.
Note that the module version is embedded in the module jar file
name. The file object representing the patched module can be
created using information from the module start list. Patch
directories reside under the Home directory and are qualified by
product/release/maintenance pack.
[0140] To accommodate use of custom patch profiles, the Launcher
can add a new optional flag to allow the customer to select a
custom patch profile. Concurrently, the Feature Registry API can
provide the ability to optionally specify a custom patch profile
applicable to module requests. In one embodiment, when handling
requests involving custom patch profiles, two differences apply to
the processing described above. [0141] Only entries identified as
belonging to the specified patch profile are selected for
processing. [0142] The file object representing the patched module
is created using a path that includes the custom patch profile
directory tree.
[0143] Module patch un-installation can require additional handling
to reverse processing and related meta-data specific to OSGi
runtime requirements as compared to a pure classpath patch.
[0144] Artifacts can be removed from the patch classpath using the
existing Patch Management System mechanism applicable for
classpath-based patching.
[0145] The following steps can change the state of the target
system to remove any artifacts or meta-data relating to the patch
being un-installed. Note that the state need not be restored to
that of the system prior to the original patch install, as other
patches may have been installed during the interim between patch
install and un-install. Standard patch dependency checking can
apply prior to initiating patch un-installation.
[0146] In one embodiment: [0147] 1. When un-installing the only
patch currently applicable to a given module, remove the patched
module from the system. [0148] 2. If multiple patches are
associated with a given module, determine if the patch being
un-installed is the latest patch applied to the module. If it is
the latest patch, re-inject artifacts from the immediately prior
patch. [0149] 3. Modify the patch backup definition file to show an
updated sequence of patches applied to the target module. If
un-installing a patch that is not the latest patch applied to the
module, do not modify the patched module. Remove meta-data in the
patch backup definition file that relates to this patch in the
sequence of patches applied to the module. [0150] 4. Remove the
corresponding entry in the patch module list under the "patch"
sub-directory of the common modules directory located in the BEA
Home.
[0151] For support and debugging purposes, we can provide the
ability to view a snapshot of all artifacts patched in a given
module. Information includes the artifact name and associated patch
identifier. The Patch Management System's command line utility can
invoke this function.
[0152] A patch attachment facility can: [0153] Provide a mechanism
to add patch installation as a loosely coupled yet cohesive part of
standard installation. [0154] Provide an ability to easily
configure this option as part of routine meta-data modifications to
install projects.
[0155] Build Activation can: [0156] Provide ability to enable patch
attachment facility via build/project file switch. [0157] The XML
file embodying the installer patch model can be located in a
well-known location in the install build directory structure.
[0158] The installer patch model's XML file can be referenced from
a build/project file variable.
[0159] Patch install model and usage can: [0160] Provide ability to
specify patches with component relationships via schema-based model
exposed in XML. For purpose of this document, we'll refer to the
model as the installer patch model.
[0161] Conceptually, patch installation can be filtered at two
levels, execution level and individual patch level. [0162]
Execution Level--this level simply determines if a set of patches
should be evaluated for installation. [0163] The list of patches
can be scoped at a component level. [0164] Multiple components and
associated patch lists can be included as part of the single
installer patch model instance. [0165] Patches listed under a given
component are evaluated if the component is already installed on
the system or has been selected during the current installation
session. [0166] Individual Patch Level--this level can assume
completion of the Execution Level check and that the check
indicates to evaluate individual patch entries for installation
[0167] Each patch entry can identify the patch ID. [0168] When the
installer is built, the patch ID can be used to query the Patch
Catalog to extract the product to which the patch applies. Patch
meta-data is updated to make this information available to the
installer at runtime. [0169] The Patch Management System need not
associate patches with installed components, thus we can check
against product when determining if it is appropriate to install a
patch, i.e. whether the patch application is meaningful given
installed products on the system. An alternative to this paradigm
is to require a dependent component semantic in the install patch
model. Weighing likelihood and ramifications of installing a patch
that is effective only for an optional component that is not
installed on the target system, although the parent product is
installed, versus a requirement to manually identify dependencies
in the install patch model, the better design choice appears to be
automatic detection of product rather than checking component and
requiring that this be included in the patch install model [0170]
Ideally, the patch ID can be used to query the Patch Management
System to determine if the patch is already installed. However,
this information is required relatively early in the installation
process, possibly before the Patch Management System has been
installed on the system. To determine if the patch has already been
installed, the installer should first check if the product to which
the patch applies has been installed; if not, assume the patch has
not been installed. Otherwise, the product uninstall definition can
be inspected to determine if the patch was installed via the
installer invoked patch process. If the patch is found in the
uninstall definition, the definition is updated to reflect newly
installed components that require the patch. If the patch was not
found in the uninstall definition, assume it is not installed. Note
that this might select patches that have already been installed
manually by the administrator, a situation that will be detected
later. If the patch is installed but not via the installer invoked
patch process, the patch entry can be bypassed, i.e. not processed
for patch installation. [0171] The patch ID can be used to query
the patch Management System to determine the product associated
with this patch. [0172] The Patch Management System need not
associate patches with installed components, thus we can check
against product when determining if it is appropriate to install a
patch, i.e. whether the patch application is meaningful given
installed products on the system. An alternative to this paradigm
is to require a dependent component semantic in the install patch
model. Weighing likelihood and ramifications of installing a patch
that is effective only for an optional component that is not
installed on the target system, although the parent product is
installed, versus a requirement to manually identify dependencies
in the install patch model, the better design choice appears to be
automatic detection of product rather than checking component and
requiring that this be included in the patch install model. [0173]
If the product that a patch applies to is already installed on the
system or has been selected during the current installation
session, the patch is selected for installation. [0174] Once the
patch is successfully installed via the installer invoked patch
process, an uninstall definition can be created, including: [0175]
Patch ID [0176] Evaluation level component [0177] Individual patch
level product [0178] If the patch has already been installed via
the installer invoked patch process, the uninstall definition for
the patch should be updated to reflect another individual patch
level component association.
[0179] The installer patch model can provide the ability to define
the order in which each patch is applied relative to the full list
of patches. Patch ordering can be independent of component
association.
[0180] Patch payloads can be packaged with the components that
require them. They are copied to the patch cache directory via the
normal file copy task.
[0181] Client libraries required for the patch attachment facility
are installed with a common component and will be dynamically added
to the installer class path by a task that runs after the file copy
task.
[0182] Patch installation can be tracked as part of the standard
progress monitor and UI.
[0183] Only begin and end events need be tracked as expected
duration is limited. If use cases determine otherwise, appropriate
events can be identified such that progress monitoring can reflect
actual progress more effectively.
[0184] Patch status analysis (whether patches should be applied)
can be split from the actual act of applying patches during
installation. This allows conditional inclusion of progress
monitoring for this function. Dynamic modification of the progress
monitoring process can be accomplished via several methods. The
planned implementation method is unspecified at this point and is a
lower level implementation detail.
[0185] Patch installation can be seamless, i.e. outside of
inclusion in standard install progress monitoring no other UI
elements should be affected.
[0186] Embodiments of the present invention can include
computer-based methods and systems which may be implemented using
conventional general purpose or a specialized digital computer(s)
or microprocessor(s), programmed according to the teachings of the
present disclosure. Appropriate software coding can readily be
prepared by programmers based on the teachings of the present
disclosure.
[0187] Embodiments of the present invention can include a computer
readable medium, such as computer readable storage medium. The
computer readable storage medium can have stored instructions which
can be used to program a computer to perform any of the features
present herein. The storage medium can include, but is not limited
to, any type of disk including floppy disks, optical discs, DVD,
CD-ROMs, micro drive, and magneto-optical disks, ROMs, RAMs,
EPROMs, EEPROMs, DRAMs, flash memory or any media or device
suitable for storing instructions and/or data. The present
invention can include software for controlling both the hardware of
a computer, such as general purpose/specialized computer(s) or
microprocessor(s), and for enabling them to interact with a human
user or other mechanism utilizing the results of the present
invention. Such software may include, but is not limited to, device
drivers, operating systems, execution environments/containers, and
user applications.
[0188] Embodiments of the present invention can include providing
code for implementing processes of the present invention. The
providing can include providing code to a user in any manner. For
example, the providing can include transmitting digital signals
containing the code to a user; providing the code on a physical
media to a user; or any other method of making the code
available.
[0189] Embodiments of the present invention can include a
computer-implemented method for transmitting the code which can be
executed at a computer to perform any of the processes of
embodiments of the present invention. The transmitting can include
transfer through any portion of a network, such as the Internet;
through wires, the atmosphere or space; or any other type of
transmission. The transmitting can include initiating a
transmission of code; or causing the code to pass into any region
or country from another region or country. A transmission to a user
can include any transmission received by the user in any region or
country, regardless of the location from which the transmission is
sent.
[0190] Embodiments of the present invention can include a signal
containing code which can be executed at a computer to perform any
of the processes of embodiments of the present invention. The
signal can be transmitted through a network, such as the Internet;
through wires, the atmosphere or space; or any other type of
transmission. The entire signal need not be in transit at the same
time. The signal can extend in time over the period of its
transfer. The signal is not to be considered as a snapshot of what
is currently in transit.
[0191] The forgoing description of preferred embodiments of the
present invention has been provided for the purposes of
illustration and description. It is not intended to be exhaustive
or to limit the invention to the precise forms disclosed. Many
modifications and variations will be apparent to one of ordinary
skill in the relevant arts. For example, steps preformed in the
embodiments of the invention disclosed can be performed in
alternate orders, certain steps can be omitted, and additional
steps can be added. The embodiments were chosen and described in
order to best explain the principles of the invention and its
practical application, thereby enabling others skilled in the art
to understand the invention for various embodiments and with
various modifications that are suited to the particular used
contemplated. It is intended that the scope of the invention be
defined by the claims and their equivalents.
* * * * *