WO2012072039A1

WO2012072039A1 - Software upgrade method and apparatus

Info

Publication number: WO2012072039A1
Application number: PCT/CN2011/083363
Authority: WO
Inventors: Fengkai Wang; An Liu
Original assignee: Hangzhou H3C Technologies Co., Ltd.
Priority date: 2010-12-03
Filing date: 2011-12-02
Publication date: 2012-06-07
Also published as: CN102006332B; CN102006332A

Abstract

A software upgrade method for upgrading a first software entity to a new version from a past version, the first software entity being operatively linked to a second software entity, the method comprising determining a set of file upgrade information, the set of file upgrade information comprising relationship information between said first software entity and said second software entity, version information of said new version of said first software entity, and version information of said second software entity which is compatible with said new version of said first software entity; and causing said first software entity to upgrade to said new version and said second software entity to upgrade to a version compatible with said new version of said first software entity by utilizing said upgrade information file.

Description

SOFTWARE UPGRADE METHOD AND APPARATUS

Backg rou nd

Software applications are increasingly built of software components such as software modules to cope with the increasing complexity of applications. The modular software approach is advantageous because it provides better scalability, more flexible customization, and more convenient maintenance. 'Service Oriented Architecture' SOA architecture is an example of modular software design concept which is widely used, especially for more complex applications. The SOA is a set of principles and methodologies for designing and developing software in the form of interoperable services. A typical SOA system comprises a platform (PLAT) and a plurality of software components adapted to provide different services.

Upgrading of software applications are necessary from time to time to cope with changes in user demand, changes in technology or changes in operation environment. However, upgrading of software applications comprising software related components require careful planning and consideration to materialise, especially when there is a gap of many versions between the version in use and the version to be upgraded.

Brief Descri ptio n of Drawi ngs

Examples of the present disclosure will be described by way of example with reference to the accompanying drawings, in which:

Figure 1 is a diagram schematically depicting a software application comprising software modules C1 and C2, Figure 2 is a schematic diagram depicting a software application of the SOA type,

Figure 3 is an example of a software upgrade apparatus for upgrading a software application comprising a plurality of dependent software components, Figure 4 is an example of a system comprising a client device and a server device,

Figure 5 is another example of a system comprising a client device and a server device,

Figure 6 is a schematic screen display depicting a user interface for software upgrading,

Figure 7 is a flow diagram illustrating an example software upgrade process,

Figure 8 is a schematic screen display depicting a relationship of software components before and after upgrading, and

Figure 9 is a schematic screen display depicting a user interface depicting user selectable software upgrading paths.

Detailed Description

There is provided a software upgrade method for upgrading a first software entity to a new version from a past version, the first software entity being operatively linked to a second software entity, the method comprising a processor executing instructions to determine a set of file upgrade information, the set of file upgrade information comprising relationship information between said first software entity and said second software entity, version information of said new version of said first software entity, and version information of said second software entity which is compatible with said new version of said first software entity; and to cause said first software entity to upgrade to said new version and said second software entity to upgrade to a version compatible with said new version of said first software entity by utilizing said file upgrade information.

This software upgrade method facilitates automated upgrading of software applications such that related components can be upgraded in one-go and there is no need to manually install components of a large piece of application software comprising a number of software components. The method is advantageous especially when there can be different versions of software in use and there may be a large gap between a software application in use and the version to be upgraded to.

This disclosure also provides a software upgrade apparatus for upgrading a first software entity to a new version from a past version, the first software entity being operatively linked to a second software entity, the apparatus comprising a processor and machine readable instructions executable by the processor to determine a set of file upgrade information, the set of file upgrade information comprising relationship information between said first software entity and said second software entity, version information of said new version of said first software entity, and version information of said second software entity which is compatible with said new version of said first software entity; and cause said first software entity to upgrade to said new version and said second software entity to upgrade to a version compatible with said new version of said first software entity by utilising said file upgrade information. In an example, the file upgrade information is determined by a processor 212 through a path calculation module 222 and by utilizing an upgrade information file 120. The upgrade information file 120 is usually provided by a software vendor.

An example software application 100 schematically depicted in Figure 1 comprises a first software module C1 and a second software module C2. Each of the first software module C1 and the second software module C2 is an individual software entity capable of independent existence and independent storage. The first software module C1 (as an example of a first software entity) is operatively linked with the second software module C2 (as an example of a first software entity) such that functioning of the software application 100 would require cooperative interaction between the first and the second software modules. Assuming that the first software module C1 is of version V1 , the second software module C2 is of version V1 , and it is now desirable to upgrade the application software to a new version, say V5, comprising a first software module C1 of version V5 and a second software module C2 of V2.

To facilitate upgrading of the software application 100 to a new version, an upgrade package comprising an upgrade information file adapted to facilitate collaborative upgrading of both the first and second software modules is provided. The upgrade package may be accessible for use by a user at a user terminal on specific request, or as a result of routine software solicitation update broadcast by a software provider.

The upgrade information file 120 contains the following upgrade path information: a) relationship between the first software module and the second software module, b) version information of the upgraded first software module, and c) version information of the second software module compatible with the upgraded first software module.

Assuming that the first software module C1 is the main or dominant software module of this application software the operation of which is dependent of the second software module C2, the following upgrade information file C1 _V2.xml in XML (extensible markup language) will be provided when version V2 of C1 version is released to supersede version V1 of C1 .

<!— Component ID-->

<!— Update at release of V2~>

</component>

</dependence>

</upgrade>

File 1 : release V2 upgrade information file (C1 V2.xml)

In the above version V2 release example, '<id>C1 </id>' is identification information of the software module C1 , '<versio n>V2</versio n>' is version information of the new release of software module C1 , '<u pgrade from=" V1 " to=" V2" >' is upgrade path information that the upgrade should be from V1 to V2, and '<dependence>' is an expression indicating that C1 is dependent on the software entity or entities following that expression. The first '</dependence>' expression signifies beginning of the dependence relationship while the last </dependence> expression signifies end of the dependence relationship. Likewise, the first appearance of the term co mponent inside the angle brackets '<>' signifies beginning of the component software entity specification while the last <co mponent> expression signifies end of the component specification. In this example, C1 is indicated as dependent on C2 by the expression '<co mponent id=" C2" >', and '<version>V1 +</versio n>' provides information on the version of C2 which is compatible with version V2 of C1 . XML is used here for illustration as this is language commonly used SOA developers.

The following upgrade information file in XML (extensible markup language) C1 _V3.xml will be provided when version V3 of C1 version is released to supersede versions V1 and V2 of C1 .

<! - Update at release of V3~>

</component>

</dependence>

</upgrade>

</dependence>

</upgrade>

File 2: release V3 upgrade information file (C1 V3.xml) In the above version V3 upgrade information file, the expressions such as '<upgrade from="V1 " to="V3" >', '<dependence>', '<component id="C2">', and <component> are used in the same way as the version V2 upgrade information file, and have equivalent meanings to those set out above. This version V3 release example provides two alternative ways to upgrade. The first alternative way is for upgrading when the current version of C1 in use is version V1 and the upgrade will be by direct transitioning from version V1 to version V3 of C1 as set out in the first part of the upgrade information file above. For this transition, the compatible version of C2 is version V1 and there is no need to upgrade the depending software entity C2. In the second alternative, the current version of C1 in use is V2 and the upgrade will be from version V2 to version V3 of C1 , as set out in the second part of the upgrade information file above. For this transition, as version V2 of C2 is also compatible to this version of C1 , there is no need to upgrade the depending software entity C2.

When version V4 of C1 is released, the following upgrade information file C1_V4.xml is provided. <!-- Update at release of V4 ->

</component> </dependence>

</upgrade>

File 3: release V4 upgrade information file (C1 V4.xml)

As set out in the upgrade information file above, the current version of C1 must be of version V3 to be upgradable to version V4, and the depending software C2 must be version V2 of C2.

When V5 of C1 is released, the following upgrade information file C1_V5.xml is provided.

<!-- Update at release of V5 ->

</component>

</dependence>

</upgrade>

</component>

</dependence>

</upgrade>

File 4: release V5 upgrade information file (C1 V5.xml)

As described in the upgrade information file above, version V5 of C1 can be upgraded from version V3 or version V4 of C1 . If the current version of C1 is version V3, C1 will be upgraded directly to version V5. As the version of C2 to be compatible with version V5 of C1 is V2 of C2. C2 will need to be upgraded to V2 if the version of C2 in use is version V1 . On the other hand, if the current version of C2 is already V2, there is no need to upgrade C2 in this release.

Where the version of C1 in use is version V4, only C1 needs to be upgraded to version V5 and there is no need to upgrade C2, as the version of C2 in use is already V2 for version V4 of C1 . Where C2 is dependent on another software entity, the system will look for an upgrade information file C2_Vn.xml of a similar nature to facilitate upgrade of C2, where n is an integer representing the version number of C2.

While, in this example, the software application 100 only contains two software entities, namely, C1 and C2, with software module C1 depending on software module C2, it will be appreciated that the software application 100 may contain more than 2 software entities, and the general principles described above will apply mutatis mutandis without loss of generality.

The software application 102 depicted in Figure 2 is based on the 'Service Oriented Architecture' (SOA) and comprises a virtual platform framework (PLAT) and a plurality of software components (componentl to componentn, where n is an integer). In this SOA architecture, PLAT is adapted to implement unified management and access control of resources while the components perform various service or application functions. Assuming that component n (componentn) of the software application is dependent on PLAT and component 1 (componentl ) to component n-1 (componentn-1 ), the following dependence file will be provided at the time of release of version V1 of component n. <deploy-config>

<!— Component ID-->

<id>Componentn</id>

<!— Component version information -->

<!— Component dependence relationship

</component>

</component>

</component>

</dependence>

< /upgrade >

</deploy-config > File 5: component n dependence information file

Assuming that a new release of component n (componentn) is now available and the upgrade information file below is provided.

<deploy-config>

<!— Component ID-->

<id>Componentn</id>

<!— Component version information -->

</component>

</component>

</component>

</dependence>

< /upgrade >

</deploy-config > File 6: component n upgrade information file

In this release, there is no need to upgrade PLAT, while component 1 needs to be upgraded from version V3 to version V4, and the component n-1 is required to upgrade from version V3 to version 6. Accordingly, the system will search for the upgrade information files of component 1 and component n-1 to facilitate upgrade in the same manner as that described in relation to software application 100.

To provide further convenience, the locations of the relevant versions of the software components are provided in an example upgrade path instructions below. <!— Upgrading path~>

<update-path>

<step>

<dir>"c Asof tware\pl at V2 "</d i r> </component>

</step>

<step>

<dir>"c:\software\Component1 V4"</dir>

</component>

</step> <step>

<dir>"c:\software\Componentn-1 V7"</dir>

</component>

</step>

<step>

<dir>"c:\software\Componentn-1 V8"</dir> </component>

</step>

</update-path>

File 7: upgrade path instructions

This above upgrade path instructions can be incorporated in the upgrade information file or in a separate file accessible by the upgrade processor on instructions of an operator.

In another example, the upgrade of component n in the SOA application requires upgrade of 4 dependent software components, namely, PLAT, component 1 , component 3 and component 5, and all from version V2 to V3, and the upgrade needs to follow a specific sequence. The following set of upgrade sequence instructions is provided as an example. PLAT V2->PLAT V3-> Componentl V2-> Componentl V3-> Components V2-> Components V2-> Components V3-> Components V3)

File 8: upgrade sequence instructions

Figure 3 depicts an example apparatus 200 adapted for upgrading a software application 104 which comprises a plurality of software entities (C1 , Cn) in dependence relationship. The software application 104 is of the type of software applications as depicted in Figure 1 . The apparatus 200 comprises a processor 212 and a memory 214 (e.g. RAM, hard disk etc) and a cluster of upgrade modules including an upgrade path calculation module 222, a software upgrading module 224, a software management module 226, and an upgrading execution module 242. These upgrade modules may be implemented as machine readable instructions stored in the memory and executable by the processor.

The processor 212 obtains an upgrade information file 120 and then saves the upgrade information file in the memory 214 so that the information is stored for later use when there is a need to upgrade the software application.

The upgrade path calculation module 222 is provided to determine the upgrading path information with reference to information contained in the upgrade information file 120. The upgrading path information can be determined according to the version information of the application software in use and the version information to be upgraded to contained in a set of file upgrade instructions contained in an XML file of the upgrade information file. The upgrade path calculation module 222 may also be adapted to determine the sequence relationship among the software components when such a need is present.

The software upgrade module 224 is adapted to locate and obtain various software components which are necessary to upgrade the application software 104 according to information of the upgrade information file 120.

The software management module 226 is adapted to store the various software components on the memory 214, and to record their individual version information as well as their locations for subsequent retrieval.

In this example, the upgrade path calculation module 222, the software upgrading module 224, the software management module 226, and the upgrading execution module 242 are stored on the memory for use by the processor to upgrade the software application. However, it will be appreciated that the various modules can be realised by software, hardware, or a combination or hybrid thereof. When a software application needs upgrading, an operator will instruct the apparatus to upgrade the software application and the processor 212 will cause the path calculation module 222 to obtain and store the file 120 on the memory 214. After the upgrade information file 120 has been received, the processor 212 will determine the software components which are required to upgrade, the paths to obtain the upgraded software components and determine the sequence, if any, which must be followed to facilitate upgrading. Next, the processor will instruct the software upgrade module 224 to locate and obtain the various software components which are necessary to upgrade the software application 104. After that, the processor 212 of the apparatus 200 will cause the software management module 226 to save the various upgrading software components on the memory and keep a record of their version information as well as their storage location. Finally, the processor 212 will cause the upgrading execution module 242 to execute the software upgrading using the various upgrading software components according to a sequence set by the path calculation module 222.

An example system 400 adapted to implement upgrading of a software application comprising a plurality of software entities in depending relationship will be illustrated by way of example with reference to a client device 220 and a server device 240 depicted in Figure 4.

In this example, the client device 220 is adapted to provide upgrade instructions with reference to version of the software application in use and the server device 240 is adapted to execute the upgrade instructions such that software application resident on the server device is brought into a new version after the upgrade. The client device comprises a processor 212, a memory 214, and a cluster of upgrade modules including an upgrade path calculation module 222, a software upgrading module 224, software management module 226, and a first communication module 228. The server device comprises a processor 243, a memory 245, an upgrade execution module 242, and a second communication module 248 which is adapted to facilitate data communication with the first communication module 228 of the client device 220. The upgrade path calculation module 222, the software upgrading module 224, the software management module 226, and the upgrading execution module 242 are for the same purpose as the modules described with respect to the apparatus 200 and have the same functions. The first three modules, namely, 222, 224 & 226 are stored in the memory 214 of the client device while upgrading execution module 242 is stored on a memory 245 of the server device 240.

In another example system 410 depicted in Figure 5, the server device 240 additionally includes a version detection module 244 and an upgrade progress report module 246. The version detection module 244 is adapted to determine the version of the software application in use, and to provide the version information to the client device 220 via the second communication module 248. The upgrade progress report module 246 is adapted to provide upgrade progress report to the client device, for example, by means of the display screen of Figures 8 and 9.

An example use of the apparatus 400 and 410 will be described with reference to the flow diagram of Figure 6 and user interactive screen of Figure 7. In use, the client device 220 will activate the software upgrade procedures, for example, by actuating a button 602 of Figure 7. When this happens, the client device 220 will determine the new version of the software application to be upgraded to at block 501 and initiate the upgrading process at the client device at 502. At 503, the client device 220 will use the path calculation module 222 to determine the upgrade path information according to the version information of the software application in use. At 504, the software management module 226 of the client device 220 will select, obtain and save software components of the correct versions. At 505, the software upgrading module 226 will send the various software components and the associated upgrade sequence to the server device 240. At 506, the upgrading execution module 242 of the server device 240 will execute upgrade instructions and upgrade the software sequentially according to the result of the upgrade path calculation module 222. Where an upgrading progress report module 246 is also provided, the progress will be displayed at the client device 220, for example on a display screen such as that shown in Figure 8. In addition, the location of the software components can be found from a user interface such as that shown in Figure 9.

In another application of the apparatus of Figures 4 and 5, the executable files of the application software are stored in the client device 200. In such a case, the executable files of the upgraded software application are sent by the server device 240 to the client device 220 for storage on the memory of the client device 220.

While the above disclosure has been explained with reference to the above examples, it will be appreciated by persons skilled in the art that the examples are only for illustration and should not be construed as limiting the scope of the disclosure.

Claims

CLAIMS:

1 . A software upgrade method for upgrading a first software entity to a new version from a past version, the first software entity being operatively linked to a second software entity, the method comprising a processor executing instructions to:

- determine a set of file upgrade information, the set of file upgrade information comprising relationship information between said first software entity and said second software entity, version information of said new version of said first software entity, and version information of said second software entity which is compatible with said new version of said first software entity; and

- cause said first software entity to upgrade to said new version and said second software entity to upgrade to a version compatible with said new version of said first software entity by utilizing said file upgrade information.

2. A software upgrade method according to Claim 1 , wherein the set of file upgrade information comprises a set of upgrade instructions contained in an upgrade information file.

3. A software upgrade method according to Claim 2, wherein the set of upgrade instructions comprises alternative upgrade instructions for upgrading said first software entity from a plurality of past versions to said new version.

4. A software upgrade method according to Claim 2, wherein the set of upgrade instructions comprises alternative upgrade instructions for upgrading said second software entity to the version compatible with said new version of said first software entity.

5. A software upgrade method according to Claim 2, wherein the set of upgrade instructions comprises location information of said new version of said first software entity.

6. A software upgrade method according to Claim 2, wherein the set of upgrade instructions comprises location information of said version of said second software entity compatible with said new version of said first software entity.

7. A software upgrade method according to Claim 2, wherein the set of upgrade instructions comprises sequence information setting a sequence for upgrading said first and said second software entities. 8. A method according to Claim 2, wherein the set of upgrade instructions is in XML.

9. A software upgrade method according to Claim 1 , wherein said first software entity and said second software entity are related software components of a larger program. 10. A software upgrade method according to Claim 1 , wherein said first software entity and said second software entity are related software components forming a service-oriented architecture.

1 1 . A software upgrade method according to Claim 1 , wherein the method comprises:- - determining said set of file upgrade information at a client device; and

- upgrading said first software entity and said second software entity at the client device using software upgrade components obtained according to said set of file upgrade information.

2. A software upgrade method according to Claim 1 , wherein the method comprises:-

- determining said set of file upgrade information at a client device; and

- upgrading said first software entity and said second software entity at a server device using software upgrade components obtained according to said set of file upgrade information.

3. A software upgrade apparatus for upgrading a first software entity to a new version from a past version, the first software entity being operatively linked to a second software entity, the apparatus comprising a processor and machine readable instructions executable by the processor to:

- cause said first software entity to upgrade to said new version and said second software entity to upgrade to a version compatible with said new version of said first software entity by utilising said file upgrade information.

4. A non-transitory storage medium storing machine readable instructions executable by a processor to:-

- determine a set of file upgrade information, the set of file upgrade information comprising relationship information between said first software entity and said second software entity, version information of said new version of said first software entity, and version information of said second software entity which is compatible with said new version of said first software entity; and - cause said first software entity to upgrade to said new version and said second software entity to upgrade to a version compatible with said new version of said first software entity by utilizing said file upgrade information.