Patent Application
20070240233
The subject matter described herein relates to enforcing software feature limits. More particularly, the subject matter described herein relates to methods, systems, and computer program products for identifying and enforcing software feature limits across different hardware platforms, software releases, and tiers.
Feature limits are limits on the operational capabilities of software. Feature limits may be imposed because of limits of the underlying hardware, limits of the software, or for marketing reasons. For example, software developed for disk storage arrays may be used to copy information from one array to another array or between disks within the same array. The software may include a tier one version that allows 100 simultaneous disk copy sessions and a tier two version that allows only 50 simultaneous disk copy sessions. The developer may charge more for the tier one version to provide a customer with additional capabilities.
One method for enforcing software feature limits is to hard code the limits within the software programs. For example, the feature limit may be coded in a program as a constant. Different constants may be coded for different hardware platforms, software releases, and tiers to provide different capabilities for each combination. However, as the number of hardware platforms, software releases, and software tiers increases, hard-coded solutions unnecessarily increase the complexity of the software.
One solution for enforcing feature limits on different hardware platforms is to store a feature limit parameter in a registry present on the hardware platform and have the software read the parameter. One problem with this approach is that it does not allow different limits to be enforced based on different software tiers. In addition, if a limit is changed due to installation of a new software release. The new software may need to use the old feature limit parameter until the new software has been committed (explained below). Once the software has been committed, and there is no way to revert back to the old software, then the new limit can be used.
Still another problem associated with updating software feature limits occurs when it is desirable to upgrade directly from one release to a new release where there are intermediate releases between the existing release and the new release and where the intermediate releases and the new release have increased feature limits. For example, it may be desirable to upgrade from release 1 to release 3 where releases 2 and 3 have increased feature limits. When the system starts running release 3 code, it may be desirable to use release 1 feature limits until the release 3 software is committed. In a hard-coded solution, the release 3 software can only apply the release 3 feature limits.
Accordingly, in light of these difficulties associated with conventional methods for identifying and enforcing software feature limits, there exists a need for methods, systems, and computer program products for identifying and enforcing software feature limits across different hardware platforms, software releases, and tiers.
Methods, systems, and computer program products for identifying and enforcing software feature limits are disclosed. According to one method, a feature limit data structure is stored on a hardware platform. When a program is initialized, its release level is determined. The program invokes a feature limit manager independent from the program with at least a feature identifier, a software release level, and a software program identifier as input to the feature limit manager. The feature limit manager accesses the feature limit data structure using the received program identifier, release level identifier, and feature identifier. The feature limit manager returns a limit for the software feature. The program stores and enforces the limit during execution of the program.
The subject matter described herein for identifying and enforcing software feature limits may be implemented using a computer program product comprising computer executable instructions embodied in a computer readable medium. Exemplary computer readable media suitable for implementing the subject matter described herein include chip memory devices, disk memory devices, programmable logic devices, application specific integrated circuits, and downloadable electrical signals. In addition, a computer program product that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.
Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings of which:
According to one aspect, the subject matter described herein includes a system that resides on a hardware platform for identifying and enforcing software feature limits. In
One problem associated with enforcing feature limits on a hardware platform such as the CLARiiON® platform is that different versions of the CLARiiON® platform may require different software feature limits. Examples of different versions of the CLARiiON® platform for which different software feature limits may be enforced include the CX500, the AX100, or the CX700. In addition to enforcing different software feature limits for different hardware platforms, it may be desirable to enforce different software feature limits based on software release level and software tier. As used herein, a software tier refers to a version of a program within the same release level that has different capabilities. For example, an application that copies data to remote disk storage array is referred to as SAN Copy. SAN Copy is available in two tiers—SAN Copy and SAN Copy Lite. SAN Copy and SAN Copy Lite may be available in the same software release level. However, SAN Copy may allow 100 simultaneous copy sessions to be open while SAN Copy Lite only allows 50. The system illustrated in
In
The function call used to invoke feature limit manager 104 may specify the name of the program for which the feature limit is sought, the software release level, the software tier name, and the feature name. The software release level, the software tier name, the feature name and/or any other parameters may be provided as a single combined parameter in the function call or as separate parameters without departing from the scope of the subject matter described herein. For example, in one implementation, the function call may include a pointer to a structure that contains all of the parameters. In an alternate implementation, the software release level, the software tier name, the feature name, and/or other index data may be provided as separate parameters to the feature limit manager function call.
Feature limit manager 104 may use these parameters to access feature limit data structure 106 and obtain the appropriate feature limit value to the application. Feature limit data structure 106 may include entries storing feature limits for a plurality of different features. Each entry may be indexed by at least the program name, software release level, and feature name. A common feature limit data structure including feature limits for different hardware platforms may be stored on a group of different hardware platforms. As such, each entry in feature limit data structure 106 may also be indexed based on a hardware platform identifier. In addition, to provide support for enforcing different feature limits by based on software tiers, at least some entries in feature limit data structure 106 may be indexed by software tier names. In an alternate embodiment, feature limit manager 106 may be specific to a hardware platform. In such an implementation, the hardware platform identifier could be omitted as an index parameter in data structure 106
In one optimization of the subject matter described herein, a feature limit data structure specific to a hardware platform may be copied into the registry of the hardware platform at the time a software package is installed on the hardware platform. The feature limit data structure may contain feature limits that are specific to the hardware platform. Each time the feature limit manager is called when new releases are installed, it is not necessary to provide the hardware platform identifier as an input parameter, because the table stored in the registry is specific to the hardware platform on which it is installed. Copying a hardware-specific table at package install time reduces the storage requirements and lookup time over an implementation where a non-hardware-specific data structure is used for all feature limits.
In step 204, a release level of the software is determined. As will be described in detail below, in some implementations, a separate commit operation is required to commit to the current release level. In such an implementation, if the current release level has been committed to, that release level, which is referred to as the commit level, is used to determine feature limits to be applied to the software. In implementations where a separate commit operation is not required, the release level of the software being installed may be used to determine the appropriate feature limits. An example where a commit operation is performed to commit to the current release level will be described in detail below.
In step 206, the software being initialized calls the feature limit manager with input that includes at least the program identifier, the software release level, and the feature identifier. The software tier name and the hardware platform may be provided as optional parameters with multiple tiers and/or multiple hardware platforms are present in the same feature limit data structure.
The following is a specification of a function call that may be used to invoke a limit manager and obtain a feature limit according to an embodiment of the subject matter described herein:
This function returns the value of a given version of a feature limit from the Registry.
In response to the function call, in step 208 the limit manager accesses the feature limit data structure using the specified parameters, obtains the feature limit, and stores the feature limit in a memory location accessible by the calling application. In the exemplary function call above, the feature limit is stored in the memory location pointed to by the pParamVal pointer. In step 210, the software stores the limit in memory that it can access. In step 212, the software determines whether this is the last feature for which a feature limit is needed. If this is the last feature, the process of obtaining feature limits ends. If this is not the last feature, control returns to step 206 where the feature limit manager is called to obtain a limit for the next feature.
In the example function call above and in
As stated above, a software feature limit manager and data structure may allow different feature limits to be identified and enforced for different hardware platforms, different software release levels, and tiers. Table 1 shown below illustrates exemplary entries that may be present in feature limit data structure 106 for two tiers and two different release levels of the above-described SAN Copy program.
In Table 1, the first column represents different hardware platforms. In the illustrated example, the hardware platforms are different versions of the above-mentioned CLARiiON® platform. The program identifier in the second column specifies the SAN Copy program that copies data form a local storage array to a remote storage array. The third column specifies the software release level. The fourth column specifies the software tier. In the illustrated example, the tiers are “default” for the default or full functionality version of SAN Copy and “Lite” for the reduced functionality version of SAN Copy. The fifth column specifies a single feature, referred to as num_sessions, indicates the number of simultaneous copy sessions that are allowed. As can be seen, the number of simultaneous copy sessions that are allowed for the default version is twice that allowed for the Lite version and varies across different hardware platforms. In addition, the number of simultaneous copy sessions for release level 2.0 is twice that allowed for release level 1.0. Additional columns may be provided in a feature limit data structure for different features provided by the SAN Copy or other program. Providing a data structure and an associated limit manager that allow such limits to be easily identified for different software release levels and tiers and across different hardware platforms simplifies software design and allows easy modification of feature limits. For example, feature limits can be modified by altering the feature limit data structure when new software releases or tiers are loaded onto hardware platforms.
As stated above, the subject matter described herein may be used to determine feature limits when the separate step of committing to a current level of software being installed is required. A commit operation is a one-way operation that allows the current release level to be committed to for feature limits purposes. Once a commit operation is performed, the prior software may be incompatible with the current feature limits. For example, if a user is running release level 3 of SAN Copy, which allows 50 simultaneous disk copy sessions, and the user installs release level 4, which allows 100 simultaneous disk copy sessions, once the user commits to release level 4, the user cannot run release level 3 because the feature limits for release level 4 are incompatible with those of release level 3.
In one exemplary implementation, during installation, the software being installed may call the feature limit manager twice—once to obtain the feature limits for the current release level to which the administrator has committed and again to obtain the feature limits for the release level being installed. Both sets of feature limits may be stored in memory accessible by the software. Accordingly, if the administrator later commits to the new software release, the software may dynamically start using the feature limits for the new release level.
In step 404, a release level of the software is determined. In step 406, the commit level is determined. As stated above, the commit level is the level associated with the software release to which the user has committed. The commit level may be the current release level for the software being installed if the user has committed to the current release level. Alternatively, the commit level may be the level corresponding to a previous release level to which the user or operator has committed. The commit level may be stored in persistent storage associated with a hardware platform.
In step 408, the feature limit manager is called with the release level of the software being installed to obtain a feature limit for a particular feature. As described above with regard to
As stated above in the background section, it may be desirable to upgrade from one release level to a new release level where there are intermediate releases and where the intermediate and new release levels have increased feature limits. In such an implementation, the feature limit data structure may store feature limits for the current release and all previous releases. If it is desirable to upgrade from release 1 to release 3 where both releases 2 and 3 have increased feature limits, storing feature limits for all prior releases in the feature limit data structure allows the release 3 code to begin execution using release 1 feature limits. The table also allows the software to switch to release 3 feature limits when the release 3 software is committed.
It will be understood that various details of the invention may be changed without departing from the scope of the invention. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.
