Patent Application
20050177826
This invention relates to systems, methods, and computer program products for coordinating software components in a software environment.
2. Background and Relevant Art
Computerized, electronic systems are increasingly common, in part because such computerized systems automate much of what people previously had to perform manually. Accordingly, computerized systems have added a certain amount of efficiency to people's ability to perform tasks.
The process of generating computerized instructions (also referred to herein as “software” or “programs”) for a computerized system is somewhat involved. Ordinarily, a software developer must first think of the desired functions or results that the program should perform, and then enter corresponding text-format instructions into an electronic text file, typically in the form of programming source code. In some cases, such as with interpreted programming languages (e.g., Javascript, Perl, etc.), a computerized system directly interprets entered text-format instructions, and performs the desired function. In other cases, such as with compiled programming languages (e.g., C#-pronounced “C sharp”, C++, etc.), text-format instructions are first compiled into object or machine codes that the computerized system can execute.
With more complicated programs, developers will sometimes implement the program's functionality in a number of interoperating “components”. Generally speaking, components (or, program components) are sets of computer-executable instructions, much like a larger application program, although tending to be smaller and less complicated since they are typically geared toward providing one or few functions. Since a given component can run sometimes as an independent program, and can also communicate with other components, a more complicated program can also sometimes be referred to interchangeably as a “component”. Furthermore, components can be referred to generally as either a “requesting component” or as a “target component”, although such a designation may be arbitrary depending on which component or program is accessing the other.
In any case, a program designer can design one component on a computerized system to request access to any number of the computerized system's other components. Target components may include functions that provide basic information such as the user's name and age, or that provide more complicated information such as the user's level of use or sophistication with a given application program. Software components can also provide system functions such as executing a command to open a file, indicating communication protocols so that one component or program can interact with still other components, and so forth. Of course, one will appreciate that a large operating system can include many components that are configured to operate with multiple different programs, and vice versa.
Generally, a requesting component includes a reference to a target component. It may be that a requesting component references a specific version of the target component (a strict reference). Referencing a specific version of target component may occur, for example, when a developer of the requesting component has prior knowledge of the target component and desires to make the requesting component expressly dependent on a specified version of the target component. For example, a requesting “component 1” may be configured to reference a target “version 1.1” of “component 3” to cause “component 1” to expressly depend on version 1.1” of “component 3. On the other hand, it may be that a requesting component references a target component that may or may not even exist when the requesting component was developed (a loose reference). Thus, a developer references a target component without prior knowledge of the target component. Accordingly, the requesting component may discover the existence of a version of the target component at run-time. For example, at run-time “component 1” may discover “version 2.1” of “component 3”
Unfortunately, there exist a number of disadvantages to implementing program components in the overall software design process, whether requesting components reference target components strictly or loosely. For example, when a user updates a target program that is referenced by one or more requesting components, the one or more requesting components may fail if the upgraded version of the target component turns out to be incompatible with the one or more requesting components. This problem can occur when the developer of the requesting component is not able to anticipate the number and type of changes that the developer of the relevant target component may implement in the future. By contrast, system policies prohibiting target component updates, or that prohibit component updates from overwriting prior versions of the target components, can result in systems that are quickly outdated, or that can become inefficient and bulky.
Some attempts to overcome these problems have included system administrators trying to manage strict and loose references to different versions of target components in the same system. In such a scenario, a computerized system identifies the version number of a given target component when it is installed on the computer system, or when the target component is first run. The computerized system then stores the identified target component information along with other information about any other versions of the target component that have also been installed on the system. When a requesting component on the computerized system requests access of a target component, the computerized system then matches the requesting component to the requested version of the target component, as appropriate.
Unfortunately, there exist still a number of disadvantages to this type of system. For example, the only information available for a target component when it is installed on the system may be the version of the target component. However, the system cannot identify whether the particular version of the target component is an upgrade of a prior version of the target component. The system also cannot identify whether a developer intends to upgrade the particular version of the target component at some later point in time, since that information is unknown. This information, as well as other necessary operating parameters must be supplied by the system administrator.
For example, a system administrator must try to configure a system based on what little information about the given target component is available, or what the administrator expects, and then provide this information about the target component to the system when the given target component is installed, or first run. In particular, the system administrator must often provide access rules for different target components that indicate whether some requesting components are required to access specific versions of other target components, and whether still other requesting components are allowed to access updated versions of other target components, and so forth. The system administrator must also provide any other information to the system as conflicts between versions of requesting and target components are realized. Thus, when a requesting component requests a given target component, the system typically grants access to the target component based on the version of the target requested, any versions of the target component stored on the system, and any other system administrator-supplied information.
One will appreciate, however, that this type of system that mixes strict and loose references to target components can be unduly complicated for system administrators. This is particularly true since system administrators are not always privy to what a third-party developer has in mind when the third-party developer is writing a given target component. Furthermore, system administrators cannot always anticipate whether certain target components are intended to be compatible with other versions or types of requesting components. This is particularly true for large systems where large numbers of requesting components are configured to access a wide variety of target components in any given number of ways.
Accordingly, an advantage in the art can be realized with systems, methods, and computer program products that allow present and future versions of requesting and target components to cooperate in a computerized system as configured. In particular, an advantage in the art can be realized with systems and methods that allow such component cooperation automatically, such that programs and components can continue to work effectively with little or no input from a system administrator.
The present invention solves one or more of the foregoing problems in the prior art with systems, methods, and computer program products that allow program developers to easily accommodate changes in components, modules, and operating systems without impairing program function. In particular, systems are disclosed that allow programs and components that access each other through static or dynamic references to compatibly coexist in an operating system.
In at least one exemplary implementation of the present invention, a determining module can receive a request to access a specified version of a target component from a requesting component. The request may include the versioning policy of the specified target component. Alternately, the determining module can identify the versioning policy of the specified target component. For example, a versioning policy can be included in a data field within the target component. Identification of the versioning policy and specified version can be done in response to the request, when the target component is installed, or when the target component is deployed on the computerized system. Other policies, such as, for example, component scope, can also be identified, as well as any system administrator-provided policies where appropriate. A requesting component is therefore granted access to an appropriate version of the target component primarily based on information contained within the request and contained within the target component.
In another exemplary implementation of the invention, the determining module receives a target component upgrade, and can identify a versioning policy that is associated with the target component and/or the requesting component. Based on the information provided in the versioning policy, the determining module can replace the target component with the upgraded component, or can simply add the target component upgrade to the system so that the original and upgraded versions of the target component coexist. Hence, upgrades are processed for target components as appropriate for requesting components, such that any requesting component that accesses the target component will continue to access the original or prior version of the target component if necessary.
Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.
In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
The present invention extends to systems, methods, and computer program products that allow program developers to easily accommodate changes in components, modules, and operating systems without impairing program function. In particular, systems are disclosed that allow programs and components that access each other through static or dynamic references to compatibly coexist in an operating system. The embodiments of the present invention may comprise a special purpose or general-purpose computer including various computer hardware, as discussed in greater detail below.
Embodiments within the scope of the present invention also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.
In addition, a “component”, for the purposes of this specification and claims will be understood to include any form of executable instructions that can be run on a computerized system, such as, for example, an interpreted text format file, as well as a file that has been compiled into machine-readable instructions. The term component, therefore, can include both larger application programs and systems that provide a large variety of functions, as well as smaller program and/or system components that provide other components or programs with specific functionality. Furthermore, although some distinction will sometimes be made in this specification between “applications”, “application programs”, “programs”, and components, the distinctions are merely one of convenience in order to clarify, usually, that one set of executable instructions are requesting, or are receiving a request, to access another component since each can be properly be referred to as a component. Hence, the terms “requesting component” and “target component” can include any of the foregoing executable instructions, as will be further detailed herein.
Embodiments of the presentation invention can access components that have been classified as “platform” or “library” components. “Platform” components are components that can be accessed by multiple other components or programs in a computerized system. Platform components are normally accessed only in the most recent form, or upgraded form, such that a requesting component may simply request the target component generally, or a minimum version of the target component, rather than request a specific version of the target component. Thus, the determining module may, for example, be configured to provide a version of a platform component other than the most recent version. In theory, platform components can be overwritten by a component upgrade when the upgrade is received, although there are reasons why this may not be done in practice. Platform components may also sometimes be referred to as “binary compatible” components. By contrast, library components are accessed by another component or program only if precisely the same version of the library component has been referenced.
As depicted in
In any case, a requesting component 105 can initiate a component access request 110 through the determining module 100, where the request indicates that the requesting component 105 is configured to access a given version of a target component 120, 125, and 130. In some implementations, the request 110, can be a reference found in the source code of the requesting component 105 when the requesting component 105 is first installed on a given computerized system (not shown). Alternatively, a request 110 can be made by the requesting component 105 when the requesting component 105 requests access of a given version of a target component, such as components 120, 125, and 130, at run time.
A “versioning policy”, for the purposes of this specification and claims includes any of a given set of properties that can be conveyed from a target component (e.g., 120, 125, 130) to a determining module 100. The versioning policy 131, 132, or 133 specifies whether the corresponding target component 120, 125, 130 can be used instead of a version of the given target component with a lower version number. The versioning policy can include additional information intended to be used by the determining module 100 to decide whether the target component can be used in a given configuration. Thus, the versioning policy 132 may specify that target component 125 (version 1.2) can be used when version 1.1 is requested. In some embodiments, the versioning policy will be found in a predefined location within a target component. In other implementations, the versioning policy can be conveyed to the determining module 100 when the component is installed on the system, or when a first request is made to access a given component, and so forth.
Accordingly, a requesting component can request access to a target component by requesting a specific version of the target component, e.g., request 110 for “component 1” “version 1.1”. If the requesting component 105 requests, or is configured to work with a specific version of a target component, determining module 100 can provide the requesting component 105 with access to a specific version of the component, depending on the versioning policy 131, 132, 133 that is present in the target component. As shown in
By contrast, in some embodiments, a request for one version of a component results in access to another (e.g., updated or more recent) version of a component. For example, request 100 may be a request to access “version 1.1” of “component 1”. However, versioning policy 131 may indicate that “version 1.1” is a platform component (and thus a most recent version of “component 1” is to be provided in response to a request). Furthermore, in some implementations there may nevertheless be multiple versions of a given platform component on a system.
As such, the requesting component can also include information in its request that indicates the lowest possible version of the platform target component that the requesting component 105 can accept. For example, it may be that requesting component 105 requests “version 1.4” of component 1” and that lower versions of “component 1” are not to be returned in response to the request. Accordingly, determining module 100 can provide requesting component 105 with access to “version 3” of “component 1”, even though “version 1.1” and “version 1.2” are accessible.
When all accessible versions of a requested component have version designations lower than a specified requested version, determining module 100 can return an appropriate response (e.g.., an error message) to a requesting component. For example, when determining module 100 does not have access to “version 3” of “component 1”, determining module 100 can send an error message to requesting component 105 in response to a request for “version 1.4 or higher” of component 1”.
It may be that a version number includes two parts, a version and a servicing. Components that have a version number indicating an updated servicing are allowed to replace components that have version numbers indicating older servicing. Utilizing servicing values to facilitate component replacement is particularly advantageous for implementing minor changes that have a reduced likelihood of causing incompatibility with other components, for fixing bugs, or for fixing security issues whether related to library or platform components. That is, servicing values can facilitate “patching” a version of a component. For example, if target component 120 is identified as a library component (such that version 1.1. of the target component is not to be replaced), a developer can still update the target component 120 by updating (e.g., incrementing) a servicing value in the component's version number. Accordingly, the updated target component 120 would essentially be a different servicing of “version 1.1”.
As depicted, components 210 and 215 include versioning policy information, such as, for example that upgraded component 210 is a “version 3” upgrade of “component 2”, and that the component is a platform component. As well, component 215 can include information in the form of a versioning policy that the component 215 is library component, or that component 215 otherwise configured such that requesting components can be given access to the specific version represented by component 215.
In response to receiving the components 210 and 215, the determining module 100 determines whether to retain prior versions (which may be referred to as “side-by-side” updating) or replace prior versions (which may be referred to as “in-place” updating) of each received upgraded component. For example, as shown in
More specifically, in response to receiving the component 210, the determining module 100 can identify that, since “component 2” is platform component, requesting programs and components will be given access to the most recent version of component 2. Accordingly, determining module 100 can determine that component 235 is to be replaced with component 210.
For example, a versioning policy that is associated with a given target component 300 can include a set of component scope. Referring briefly back to
Component scope can also indicate larger or smaller scopes for a target component 300, 310, 315, 320, and 325. For example, “versioning policies” identified with a given component 310 can indicate that a given version of the target component 310 is required only within a certain process 342, 345, or sub-process 352, 355. As shown in
Accordingly, identification of an appropriate version of a target component can be based on other policies, such as, for example, component. A determining module can therefore identify an appropriate version of a target component based on any identified policy, such as the versioning policy and component scope of the specified target component, as well as any other system administrator-provided policies where appropriate
The present invention may also be described in terms of methods comprising functional steps and/or non-functional acts.
The method also includes a functional result-oriented step 440 of providing an appropriate target component. Step 440 can include any number of corresponding acts for implementing the present invention. However, as depicted in
Step 440 also includes an act 430 of providing an appropriate version of the target component. Act 430 can include identifying an appropriate version of the target component based on the versioning policy of the specified target component. For example, the determining module 100 can provide a requesting component 105 with a specific version of the requested target component (a library component), such as component 120. Alternatively, the determining module 100 can provide the requesting component 100 with a more recent version of a component (a platform component), such as component 130.
The method depicted in
The method depicted in
The method depicted in
The method depicted in
Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where local and remote processing devices perform tasks and are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
With reference to
The computer 620 may also include a magnetic hard disk drive 627 for reading from and writing to a magnetic hard disk 639, a magnetic disc drive 628 for reading from or writing to a removable magnetic disk 629, and an optical disc drive 630 for reading from or writing to removable optical disc 631 such as a CD ROM or other optical media. The magnetic hard disk drive 627, magnetic disk drive 628, and optical disc drive 630 are connected to the system bus 623 by a hard disk drive interface 632, a magnetic disk drive-interface 633, and an optical drive interface 634, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-executable instructions, data structures, program modules and other data for the computer 620. Although the exemplary environment described herein employs a magnetic hard disk 639, a removable magnetic disk 629 and a removable optical disc 631, other types of computer readable media for storing data can be used, including magnetic cassettes, flash memory cards, digital versatile disks, Bernoulli cartridges, RAMs, ROMs, and the like.
Program code means comprising one or more program modules may be stored on the hard disk 639, magnetic disk 629, optical disc 631, ROM 624 or RAM 625, including an operating system 635, one or more application programs 636, other program modules 637, and program data 638. A user may enter commands and information into the computer 620 through keyboard 640, pointing device 642, or other input devices (not shown), such as a microphone, joy stick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 621 through a serial port interface 646 coupled to system bus 623. Alternatively, the input devices may be connected by other interfaces, such as a parallel port, a game port or a universal serial bus (USB). A monitor 647 or another display device is also connected to system bus 623 via an interface, such as video adapter 648. In addition to the monitor, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.
The computer 620 may operate in a networked environment using logical connections to one or more remote computers, such as remote computers 649a and 649b. Remote computers 649a and 649b may each be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically include many or all of the elements described above relative to the computer 620, although only memory storage devices 650a and 650b and their associated application programs 636a and 636b have been illustrated in
When used in a LAN networking environment, the computer 620 is connected to the local network 651 through a network interface or adapter 653. When used in a WAN networking environment, the computer 620 may include a modem 654, a wireless link, or other means for establishing communications over the wide area network 652, such as the Internet. The modem 654, which may be internal or external, is connected to the system bus 623 via the serial port interface 646. In a networked environment, program modules depicted relative to the computer 620, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing communications over wide area network 652 may be used.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.
