Patent Publication Number: US-8122101-B2

Title: Methods and systems for distributing software

Description:
FIELD 
     The present invention relates to methods and systems for distributing software between systems. More particularly, the invention relates to methods and systems for distributing software that may comprise changes, including changes that may concern software components as well as data. 
     BACKGROUND 
     Enterprises and organizations of any size often rely on software applications to conduct business. To meet the specific needs of such enterprises and organizations, the built-in functionality and predefined data of software components, and/or the data itself of a software application, may be changed. The process of changing software components and/or data is referred to as customization. 
     Customization of software components and/or data may usually not, however, be performed while the software system is running. Thus, enterprises may use at least two systems during customization. For instance, the customization may be initially carried out on the first system. This system may be denoted as the customization system. The second system, on the other hand, may be denoted as the productive system. In such an arrangement, changes are transported from the first system to the second system only after those changes have been successfully tested on the first system. 
     Other arrangements may use at least three systems—a customization system, a quality assurance system, and a productive system. Again, the customization system may be used to customize the applications. The quality assurance system, however, may be used to test the changes to determine that they work correctly. The changes are thus transported from the customization system to the quality assurance system and, then, from the quality assurance system to the productive system. The transport of changes from a first system to another system is referred to herein as software distribution. 
     Typically, enterprises and organizations use many different software applications. If these software applications are customized centrally on a customization system—for example by a team of administrators—a number of different applications may be distributed from the customization system to at least a further system. Normally, different software applications provide their own distribution tools. Therefore, a number of different distribution tools and distribution methods may be necessary to distribute different software applications. However, by using different distribution tools, there exists a higher risk of making mistakes during the software distribution process. 
     Accordingly, there exists a need to simplify the distribution of software and data involving different software applications. 
     SUMMARY OF THE INVENTION 
     Systems and methods consistent with the invention relate to the distribution of software. According to one exemplary embodiment, a method for distributing software from a first system to a second system comprises determining a software object to be transported. The method stores the software object in a storage device and creates, on the first system, a transport request which comprises an object list. The method defines, on the first system, a transport container and includes a reference to the stored software object in the transport container. The method also includes the transport container in the object list of the transport request and provides the transport request to the second system. 
     Other objects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. 
     It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments of the invention and together with the description, serve to explain the principles of the invention. In the drawings: 
         FIG. 1  illustrates an exemplary embodiment of the invention comprising three systems; 
         FIG. 2  illustrates an exemplary implementation of the present invention; 
         FIG. 3  illustrates an exemplary flow diagram consistent with the present invention; and 
         FIG. 4  illustrates an exemplary export and import process consistent with the present invention. 
     
    
    
     DESCRIPTION OF THE EMBODIMENTS 
     The following description refers to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or similar parts. While several exemplary embodiments and features of the invention are described herein, modifications, adaptations and other implementations are possible, without departing from the spirit and scope of the invention. For example, substitutions, additions or modifications may be made to the components illustrated in the drawings, and the exemplary methods described herein may be modified by substituting, reordering, or adding steps to the disclosed methods. Accordingly, the following detailed description does not limit the invention. Instead, the proper scope of the invention is defined by the appended claims. 
       FIG. 1  illustrates an exemplary environment consistent with the invention. As shown in  FIG. 1 , an exemplary embodiment may include three systems  10 ,  20 , an  30 . Customization system  10  may be a system in which customization is initially made to a software application. Quality assurance system  20  may be a system in which the changes made in the customization system  10  are tested by using representative test data. Productive system  30  may be a system for normal business operations. Productive system  30  may thus be secure from any changes made in systems  10 ,  20  until those changes have been tested and are ready for transfer into productive system  30 . 
     Each of systems  10 ,  20 ,  30  may represent a heterogeneous system which may comprise computer hardware and computer software. For example, the computer software may implement an enterprise relationship management system or a supply chain management system. Further, systems  10 ,  20 ,  30  may be connected by a communication network (not shown) such as an Ethernet, Wireless LAN or other appropriate network. In a further embodiment of the invention, only customization systems  10  and quality assurance system  20  may be connected by a communication network. In such an embodiment, productive system  30  may be separate from the systems  10 ,  20  for security reasons. 
     As shown in  FIG. 1 , productive system  30  may further comprise a plurality of computer hardware systems with the corresponding computer software. This may be necessary when a complex software system needs a separate database server, file server and application server (each not shown). Similarly, while not shown in  FIG. 1 , customization system  10  and quality assurance system  20  may also comprise a plurality of computer hardware systems and corresponding computer software systems. 
     As noted above, customization may take place on customization system  10 . Customization may comprise, for example, developing new software applications, modifying existing software applications, developing new software modules, modifying existing software modules, generating new master data records and/or changing existing master data records. Further, customization may also comprise modifications to user master data and application data. 
     Systems  10 ,  20 , and  30  may implement any type of software application. For instance, systems  10 ,  20 , and  30  may include software applications such as native Windows™ applications, JAVA based applications and/or various database management systems. Software applications on systems  10 ,  20 , and  30  may also comprise operating systems for common computer systems as well as operating systems for software controlled devices, such as industrial robots. Further, systems  10 ,  20 , and  30  may include an entire software application or only a part of a software application. A software application or a part of a software application may be referred to as a software object. A software object may also contain master data, user data, application data and/or program code. 
     As shown in  FIG. 1 , all changes made in customization system  10  may be recorded to a change request file  15 , and then transported to quality assurance system  20  for validation. In alternative embodiments, however, a complete software application containing the changes may be transferred between systems, as opposed to the use of a change request file  15 . In any event, quality assurance system  20  may integrate the changes and check the validity and consistency of those changes before transferring them to productive system  30 . All changes imported into quality assurance system  20  are then delivered (as illustrated by  25 ) to productive system  30 . Thus, in quality assurance system  20 , the functionality, e.g., the changes made in customization system  10 , are tested without affecting the productive system  30 . 
     A further embodiment of the invention may comprise only two systems, namely customization system  10  and productive system  30 . In such an arrangement, customization system  10  may be used for customization as well as for quality assurance testing, and productive system  30  may be used for actual productive activities. 
       FIG. 2  illustrates an exemplary implementation of the present invention. As shown in  FIG. 2 , customization system  10  may be connected through a communication network to quality assurance system  20 . Productive system  30  may be a system without any connection to systems  10  and  20 . In  FIG. 2 , arrows between systems  10 ,  20  and  30  refer to a transportation route of the changes, e.g., changes are first transported from customization system  10  to quality assurance system  20  and then to productive system  30 . 
     During a first phase, a customization of the software application located on customization system  10  may be performed. When the customization is completed, all of the changes may be released and exported. Releasing and exporting of the changes is described in more detail below with respect to  FIG. 4 . 
     During a second phase, the exported changes, i.e. the transport request as described below with reference to  FIG. 3 , may be imported (as shown by arrow  48 ) into an import buffer  50  which may belong to quality assurance system  20 . In detail, the customized software objects may be stored (as depicted by arrow  45 ) on a separate storage device, such that import buffer  50  holds a transport request holding a references  55  to software objects  60  to be imported (as shown by arrow  46 ) into quality assurance system  20 . The storage device may belong to customization system  10  or to quality assurance system  20 . The software objects  60  should be accessible by both quality assurance system  20  and customization system  10 . 
     Further, during the second phase, the changes which have been added to import buffer  50  (or referenced by import buffer  50 ) are imported into quality assurance system  20 . Thereafter, the changes are activated within quality assurance system  20  if they have been successfully imported. Then, the imported components are then tested in order to verify various requirements, such as the changes made on customization system  10 . 
     The verified changes or a reference to the changes may then be transported, also during the second phase, from import buffer  50  to productive system  30  (as shown by arrow  49 ). The changes, i.e. the transport request, may be imported into import buffer  51  which may belong to productive system  30 . Thus, import buffer  51  may hold references to software objects  60 . If productive system  30  has no access to software objects  60  (e.g., located with customization system  10  or with quality assurance system  20 ), then software objects  60  may be transported (as shown by arrow  90 ) to productive system  30 , e.g., by storage means such as compact discs (CD), digital versatile discs (DVD) or other means. Further, the transport of software objects  60  may be carried out by a special software program which may be adapted for copying data files from a source location to a target location (e.g.; as shown by arrow  90 ), whereby the special software program has access to the source location and the target location. The transported software objects are shown by item  61  in  FIG. 2 . Afterwards, a reference  56  of import buffer  51  to software objects  60  may be altered to reference software objects file  61 . The changes may then be imported into and activated within productive system  30  as described above for quality assurance system  20 . 
       FIG. 3  illustrates an exemplary flow diagram relating to a software distribution process consistent with the present invention. For example, the process of  FIG. 3  may be used as part of the first phase described above with reference to  FIG. 2 . During customization, software applications may be customized according to given requirements. As described above, customization may be performed on customization system  10 . Systems consistent with the invention may record any changes made during customization to store those changes for future use or for transporting the customized software to different systems. Recording and storing changes may be necessary when a large number of developers are customizing the software application in parallel over a long period of time. After finishing the customization, the customized software objects may then be distributed by using the process of  FIG. 3 . 
     As shown in  FIG. 3 , the distribution system may determine a software object to be customized (step  99 ). This may be done for any software object to be customized. Therefore, step  99  may lead to a number of software objects which are to be customized and thus transported to quality assurance system  20 . 
     Because systems consistent with the invention may transport a software object to systems other than a quality assurance system, however, the description below refers to the destination of a transported software objects as a target system. In  FIG. 2 , quality assurance system  20  is illustrated as the target system during phase two, while productive system  30  is illustrated as the target system during phase three. 
     The distribution system may then copy the customized software objects into, for example, a central directory on the file system (step  100 ). The central directory on the file system may be accessible by each of systems  10 ,  20 , and  30 . Further, systems and methods consistent with the invention may copy for transport any type of software object. 
     The distribution system may then generate a transport request or, if a transport request was already created before, select a transport request (step  101 ). A transport request may include an object list identifying the customized software objects, as well as header information containing, e.g., administrative information. 
     In one embodiment, a transport request may be created automatically for each software object to be transported. However, other embodiments may use an existing transport request. In any case, a user may request the generation of a new transport request for the software objects. Further, if there already exists a transport request containing a particular software object, the distribution system may automatically select that transport request and update the particular software object in the transport request with the corresponding changed software object. 
     The distribution system may then define or create a transport container (step  102 ). The transport container may hold a reference (pointer) to a software object located in the central directory to be transported. The reference to the software object which has been determined within step  99  may then be inserted into the transport container within step  103 . In one exemplary embodiment, each transport container may hold exactly one reference to a software object. However, additional information about the software object to be transported may also be stored within the transport container, such as the type of software object. 
     The transport container holding, for example, a reference to the software object to be transported, may then be included into the object list of the generated or selected transport request (step  104 ). Thus, only the references to the software objects may be transported from system  10  to system  20 . Thus, a large number of different software objects can be transported from a source system, such as customization system  10 , to a target system, such as quality assurance system  20 . Further, distribution systems consistent with the invention may thus transport such software objects irrespective of the type of software and irrespective of the respective source locations. 
     Each defined transport container may further comprise instructions specifying how the included software objects have to be handled during the distribution process. For example, the instructions may comprise methods or references to methods which are executed before the software objects are copied into the shared directory. These methods may include compressing the software objects for the purpose of saving storage space or bandwidth of the communication network. Methods which are executed before the software objects are transported or exported are denoted as ‘before-export-methods’. 
     Furthermore, the instructions may also comprise methods which are executed after the software objects are imported into the target system. These methods may include, for example, decompressing the software objects. Methods which are executed after the software objects have been imported are denoted as ‘after-import-methods’. Generally, after-import-methods may also be used to activate the imported software objects within the target system. After-import-methods may be located with the target system or implemented by the target system. 
     Finally, the transport request is provided for further use, e.g. for importing into the target system (step  105 ). The changes which have been performed during the customization are thus exported. The exporting may store the transport request in a data file located with the shared directory on the file system. Thus, the shared directory may contain a number of different software objects to be transported a data file containing a plurality of references (pointers) to the software objects. The file system may belong to the system where the changes have been made or may be an external file system or data storage device such as a DVD or CD. 
     Providing the transport request may also include importing the transport request, e.g., the data file located with the shared directory into the import buffer of the target system (see, e.g., arrow  48  and buffer  50  in  FIG. 2 ). Thus, import buffer  50  may hold a plurality of references to software objects in the shared directory that are to be imported. 
       FIG. 4  illustrates an exemplary export and import process consistent with the present invention. As described above, during customization, one or more software objects may be changed to meet given requirements. With respect to  FIG. 4 , the software module A has been changed. Software module A may belong to a software application  11  which may be a Windows™ native application or a JAVA application or any further type of application. Each software application  11  may provide an interface  12  which may be adapted to pass the software module A to a shared directory located in file system  5 , and for passing a reference to the software module A when it is located in the shared directory. 
     After releasing the changes, the changed software objects are exported  55  via interface  12  to file system  5  which may be shared by both systems  10  and  20 . At the same time, a reference  45  to software objects  60  on file system  5  may be inserted into transport container  31 . After exporting the software objects, the transport request may be automatically added  48  to import buffer  50  of target system  20 . Thus, import buffer  50  may hold a list of transport containers which hold a number of references  45 ′ to software objects  60 . Due to security reasons, the import mechanism may be triggered manually. 
     In a further embodiment of the invention, the transport request may be exported into a data file located with file system  5 . Thereafter, the import mechanism may import that data file into import buffer  50 . 
     The import mechanism reads and copies  47  the software objects  60  located with shared file system  5  into the target system according to references  45 ′ within import buffer  50 . For this purpose, software application  11 ′ which corresponds to source software application  11  may provide an interface  12 ′ which is adapted for obtaining the exported software objects  60 . Further, interface  12 ′ may provide functionality for activating the imported software module A′. The software module A′ corresponds to the software module A. 
     In a further embodiment of the invention, the after-import-methods may be performed for importing and activating the software objects. Thus, the after-import-methods may get references  45 ′ from import buffer  50  and imports the software objects into the target system. Afterwards, the after-import-method may activate the imported software objects. 
     After software objects have been imported and activated successfully, they may deleted from import buffer  50 . The successfully imported software objects may be marked as “already imported” in order to prevent a further import of the objects. 
     For purposes of explanation only, certain aspects and embodiments are described herein with reference to the components illustrated in  FIGS. 1-4 . The functionality of the illustrated components may overlap, however, and may be present in a fewer or greater number of elements and components. Further, all or part of the functionality of the illustrated elements may co-exist or be distributed among several geographically dispersed locations. Moreover, embodiments, features, aspects and principles of the present invention may be implemented in various environments and are not limited to the illustrated environments. 
     Further, the sequences of events described in  FIGS. 1-4  are exemplary and not intended to be limiting. Thus, other method steps may be used, and even with the methods depicted in  FIGS. 1-4 , the particular order of events may vary without departing from the scope of the present invention. Moreover, certain steps may not be present and additional steps may be implemented in  FIGS. 1-4 . Also, the processes described herein are not inherently related to any particular apparatus and may be implemented by any suitable combination of components. 
     Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.