Browse Prior Art Database

A Universal Framework to Facilitate Software Dependency and Conflict Checking

IP.com Disclosure Number: IPCOM000012086D
Original Publication Date: 2003-Apr-07
Included in the Prior Art Database: 2003-Apr-07
Document File: 2 page(s) / 16K

Publishing Venue

IBM

Abstract

A universal framework to facilitate software dependency and conflict checking

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

A Universal Framework to Facilitate Software Dependency and Conflict Checking

Software dependency/conflict checking has been an essential feature in software deployment. It is also an integral part of an autonomic system which involves automated software deployment in self-healing. In general, software dependency/conflict checks require:

Canonical names for software components (products, libraries, etc.), and/or

Well-defined processes to check whether the software exists on a host. This could be done locally or


1.


2.

remotely.

Today when a software component 'A' depends on software component 'B', the common practice is to encode the logic in 'A' to check whether 'B' exists. Often times such information is not exposed for use by meta-install tools such as software distribution tools or solution deployment tools for checking remotely without transferring 'A' in its entirety to the target host.

This approach suffers two problems:

'A' needs to know or sometimes guess how to check 'B'. 'B' has this knowledge that 'A' need not and

should not be aware of. This problem is more important today since software today often install on multiple platforms and use different install/registry technologies. The dependency on 'B' by 'A' is not made available. Such information requires 'B' be canonically


1.


2.

specified so systems (such as an autonomic system) retrieving such information can identify 'B' properly. Currently, such canonical naming mechanism doesn't exist globally.

This article describes a framework that has:

A canonical naming mechanism for any software products, and

A well-defined process for sharing the existence check information during software packaging as well


1.


2.

deployment time.

This framework has a central repository (for example, a LDAP directory) that stores the following information for a software component 'B' (based on the previous example)

The canonical product name, version #, and other related product information (vendor name, address,

etc.) Information on how to check the existence of the product. Specifically this information include:


1.


2.

executable code (DLL, Java class libraries, etc.) to check the existence of the product, and/or description of how the check can done. For example, Window registry strings to check, or installp...