Abstract:
A method, system and article of manufacture are disclosed for policy-based enforcement of business requirements for a software install. The method comprises the steps of determining a policy infrastructure analogous to one or more business requirements; and embedding the policy infrastructure in a software installation process for installing a given software application. The software installation process is used to install the given software application into a computer system while ensuring that all installation prerequisites of the software application are met during the install. In a preferred embodiment of the invention, the determining step includes the step of preparing one or more policies for the business requirements, each of the policies including a condition part that evaluates either to true or false, and an action part that specifies one or more actions to be taken if the condition part evaluates to true.

Description:
FIELD OF INVENTION 
       [0001]    This disclosure is related to policy based enforcement of business requirements for software deployment, and more specifically to enforcing external installation requirements during software deployment. 
       BACKGROUND 
       [0002]    When a new software program is acquired, it usually must be installed on the target data processing system before it can be used. Typically, software programs include as a component thereof an installer, which is software that substantially automates the installation process. In addition, computer operating systems (software which coordinates resource use by, and interaction between, other software) may include an installer for use in installing drivers or other software. 
         [0003]    In addition, many commercial software programs are provided with a process by which they may be updated, and can be included as a component of the software program itself, or may be provided externally. The provision of an updating process is desirable because end users, for example, frequently modify software programs by applying bug fixes or enhancements, for example, new versions of the software. 
         [0004]    There are a number of processes available for installing and/or updating software programs. Some processes are entirely automated and substantially invisible to the user, while others are interactive. Some are complex while others are simpler. Software programs used to install new software, to install updates to software, and to uninstall (remove) software are referred to as “installer” applications, which is intended to encompass both “standalone” software programs that can be used to install a variety of software applications, for example, installers that may be provided with an operating system, as well as software programs that are adapted to install only a single software application, which may be integrated with the installation file package for that software application. Installer applications, when run, implement a software installation process. 
       SUMMARY 
       [0005]    Embodiments of the invention provide a method and system for policy based enforcement of a customer&#39;s external install requirements for software deployment, and to validate before hand whether a particular software installation would comply with a customer&#39;s business policy. An embodiment of the invention is to ensure that a software installation does not break a customer&#39;s business policy, and to embed into a software installer a Policy Infrastructure that will interpret and enforce a customer&#39;s business policies in the installation process while ensuring that the prerequisites for the software have been met. 
         [0006]    Embodiments of the invention provide a method, system and article of manufacture for policy-based enforcement of external requirements for a software install. The method comprises determining a policy infrastructure analogous to one or more requirements; and embedding the policy infrastructure in a software installation process for installing a given software application, the software application having one or more installation prerequisites. The software installation process is used to install the given software application into a computer system while ensuring that the one or more installation prerequisites are met during the install. 
         [0007]    In a further embodiment, the determining step includes the preparing one or more Policies for the business requirements, each of the Policies including a Condition part that evaluates either to true or false, and an action part that specifies one or more actions to be taken if the Condition part evaluates to true. Also, in this embodiment, a plurality of Deployment Descriptors are provided for identifying the software installation prerequisites; and the one or more actions specified in the action part of the Policies include a Deployment Descriptor Independent action, and a Deployment Descriptor Dependent action. The Deployment Descriptor Independent action performs an action specified by a user of the computer system. If the Deployment Descriptor Dependent action violates any mandatory clause of the Deployment Descriptor, then exception approval is sought to ignore the action and to continue installation of the software application. However, if the Deployment Descriptor Dependent action does not violate any mandatory clause of the Deployment Descriptor, then the action is performed. 
         [0008]    In a further embodiment of the invention, as described below in detail, is embedded a Policy Infrastructure into a software installer. The Policy Infrastructure will interpret and enforce the Customer&#39;s Business Policies in the installation process while ensuring that the prerequisites for the software have been met. 
         [0009]    Without this infrastructure, the customer will not be able to enforce or verify that the software solution complies with all his Business Policies. With no control over the solution the customer would have to manually carry out an impact analysis, which is a complicated and time-consuming task. Most customers currently overlook these Business Policy violations, as there is no way of enforcing them automatically. This results in audit vulnerability. The solution in the present disclosure, hence, provides an important assurance to customers who are currently facing such problems. 
         [0010]    This technique also makes the software install highly flexible, by allowing customers to modify deployment descriptors to suit their business needs as long as it does not conflict with the software prerequisites. Embodiments of the invention will give the vendor a competitive edge over other vendors who are not able to provide flexible solutions that accommodate the customer&#39;s Business Policies. 
         [0011]    Further benefits and advantages of this invention will become apparent from a consideration of the following detailed description, given with reference to the accompanying drawings, which specify and show preferred embodiments of the invention. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
         [0012]      FIG. 1  shows an existing software installation architecture. 
           [0013]      FIG. 2  illustrates a software installation architecture embodying this invention, when the Installer is coupled with a Policy Infrastructure. 
           [0014]      FIG. 3  depicts a high level architecture of the Policy Engine shown in  FIG. 2 . 
           [0015]      FIG. 4  shows the high level design of the policy infrastructure. 
           [0016]      FIG. 5  illustrates an method that may be used to implement embodiments of the invention. 
           [0017]      FIG. 6  is an exemplary diagram of a distributed data processing system in which embodiments of the invention may be implemented. 
           [0018]      FIG. 7  shows an example diagram of a server-computing device that may be used as a server in the system of  FIG. 6 . 
       
    
    
     DETAILED DESCRIPTION 
       [0019]      FIG. 1  shows the existing architecture of a Solution Install. This architecture, generally, includes hosting environment  12  and installation database  14 . In turn, the hosting environment  12  includes touchpoints  16 ; and the installation database  14  includes a hosting environment registry  20 , a touchpoint registry  22 , an installable unit type registry  24 , and a relationship registry  26 . The architecture of  FIG. 1  also includes a dependency checker  30 , change manager  32 , IU registration  34  and deployment descriptor  36 . The Solution Install architecture is discussed in more detail in “Simplify Deployment Tasks with Solution Install Technology”, Charlie Halloran, Jr., 10 May 2005, http://www.ibm.com/developerworks/autonomic/library/ac-sivalue/. Most installers follow the same architecture as the Solution Install, i.e., they have a deployment descriptor  36  (change plan) and similar interactions as the Solution Install. 
         [0020]    In accordance with embodiment of the invention, the process of software installation is customized and managed using a Policy Infrastructure. As discussed in detail below, embodiments of the invention enable the customer to write policies or use existing policies that will change the course of the installation to enforce Business Requirements (BR) based on the information available in the deployment descriptor  36 . The usage of instrumentation to define business policies that can be used to automate software installation through the Policy Infrastructure embedded into the software installer. 
         [0021]      FIG. 2  illustrates an architecture embodying the invention. This architecture includes the hosting environment  12 , the installation database  14 , the dependency checker  30 , the change manager  32 , and the IU registration  34  shown in  FIG. 1 . In addition, the architecture of  FIG. 2  includes a policy engine  42 , a policy repository  44  and a modified deployment descriptor  46 . Also, with the architecture of  FIG. 2 , the deployment descriptor  36  provides input to the policy engine  42 , rather than directly to the dependency checker  30 , change manager  32  and IU registration  34 . 
         [0022]      FIG. 3  shows the architecture of the policy engine  42 . In this architecture, the policy engine  42  comprises a policy manager  52 , a policy parser  54 , a data collector  56 , and an actuator  60 .  FIG. 3  also shows the policy file  44 , and a custom action  62 .  FIG. 4  shows the high level design of the policy infrastructure  70 . 
         [0023]    The solution provided by embodiments of the invention aims to use a policy repository  44  to store all the policies written by the user. The policies stored in the policy repository  44  are written to suit the Business Requirements (BR). These policies are preferably based on the deployment descriptor  36  schema used. Embodiments of this invention aims to embed a policy engine  42  that will interpret the customer&#39;s Business Policies stored in the policy repository  44  for the installer  64 . This enables the policy infrastructure  70  to enforce the business requirements over a range of solutions without being tied to a particular solution. 
         [0024]    The condition part  72  of the policy infrastructure  70  is comprised of expressions that work with the prerequisite and other requirements described in the deployment descriptor  36 . The condition can either evaluate to true or false. If it evaluates to true, then the action part  74  of the policy infrastructure  70  is executed, else the execution of that policy infrastructure  70  is skipped and normal installation is resumed. 
         [0025]    The action part  74  of the policy infrastructure  70  is comprised of custom actions or management operations and information about installable units to be used. The actuator  60  is responsible for creating a modified deployment descriptor  46  that contains the updated information. This modified deployment descriptor  46  is passed on to the change manager  32 . The installer  64  then continues normal installation. If a conflict between Dependencies and Business Requirement should arise, the policy engine  42  will ask for guidance from the user. This is as good as throwing an error, where the user would have to resolve the conflict. 
         [0026]    The architecture aims primarily at creating the best install plan that satisfies the Business Requirements for the customer in a given environment. The install plan is comprised of a good mix of Dependencies and the Business Guidelines as specified by the Policies. 
         [0027]      FIG. 5  illustrates a method  80  that may be used to practice embodiments of the invention. At step  82 , the installation is started; and at step  84 , the installer  64  from its internal location picks up the deployment descriptor  36 . At step  86 , the deployment descriptor  36  is handed over to policy engine  42 ; and at step  88 , the policy engine  42  picks up relevant Policies from the repository. Step  90  is to evaluate the policies retrieved from the repository against the deployment descriptor  36 . This is done, more specifically, by gathering data from the deployment descriptor  36 , and evaluating the condition part  72  of the policy Infrastructure  70  against the data gathered from the deployment descriptor  36 . Based on the evaluation of the condition, the actuator  60  is triggered to take the associated action. 
         [0028]    The actuator  60  can execute two kinds of actions: Deployment Descriptor Independent actions and Deployment Descriptor Dependent actions. In the case of Deployment descriptor independent actions, the actuator  60  performs the action specified by user in the decision part  74  of the policy infrastructure  70 . In the case of Deployment Descriptor Dependent actions, the actuator  60  checks to see if the action violates a mandatory clause of the deployment descriptor  36 . 
         [0029]    In case of a violation of a mandatory clause of the deployment descriptor  36  the customer is notified and exception approvals are sought to ignore violation and continue with the install. If the action does not violate any mandatory clause of the deployment descriptor  36 , then the method goes on and performs the action, i.e., changes the deployment descriptor  36  as required by the policy infrastructure  70  (for example, if the policy says min 50 MB should exist on the system at all times, the deployment descriptor  36  would be used to check for [required+50 MB] dependency). This step orchestrates the impact analysis for the actions and the steps mentioned above can be updated/modified based on the requirements. Steps  88  and  90  are repeated for all relevant policies. After this, at step  92 , the business compliant deployment descriptor  36  is provided to the installer; and, at step  94 , the Installer will go ahead and install the Business Policy Compliant Solution. 
         [0030]    For example, due to a change in the licensing terms of software such as Java (Java is a Trademark of Oracle Corporation in the US and other countries), a Company decides that it does not want to install Java on any of its systems. Under normal conditions this would require a rework on the solution or an entirely new solution. Therefore, the Business Policy of a company say Policy  2 , insists that all Java dependant installations should use only XYZ Java (“XYZ Java” is an exemplary distribution of Java). 
         [0031]    A solution, say Software Y, has a prerequisite of Sun Java. This can be represented as follows. 
       Prerequisite  1  (P 1 ): Java 
       [0032]    The Deployment descriptor  36  would have a dependency check as follows: 
       Prerequisite  1  (P 1 ) 
       [0033]      
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 If (Java==not installed) 
               
               
                   
                 {Include installable unit corresponding to Sun Java} 
               
               
                   
                   
               
             
          
         
       
     
         [0034]    The prerequisite check can be changed to look as follows: 
       Prerequisite  1  (P 1 ) 
       [0035]      
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 If ((Java==not installed) OR (Java==Sun(Oracle))) 
               
               
                   
                 {Include installable unit corresponding to XYZ Java} 
               
               
                   
                   
               
             
          
         
       
     
         [0036]    The installer (with embedded policy infrastructure  70 ) would install the solution as follows:
   1) The installation is triggered.   2) Deployment descriptor  36  is picked up by the installer.   3) Deployment descriptor  36  is handed over to policy engine  42 .   4) Policy engine  42  picks up relevant Policies (filtered by scope if required) from the Customers Business Policy Repository.   5) Policy  2  is retrieved from the repository and evaluated against the deployment descriptor  36 .   
 
         [0042]    The data from the deployment descriptor  36  (Prerequisites P 1 ) is given as input to the evaluation engine. The policy infrastructure  70  can be interpreted to mean that all software that has a Java dependency should use XYZ Java instead of Java (Sun/Oracle). The condition part  72  of the policy infrastructure  70  in this case would check to see if the installation has a Sun Java Dependency. Since the current deployment descriptor  36  has a Sun Java Dependency, the actuator  60  would be triggered to take the associated action. 
         [0043]    The actuator  60  can execute two kinds of actions, either deployment descriptor  36  Independent actions, or Deployment Descriptor Dependent actions. Deployment Descriptor Independent actions could include triggering XYZ Java installation and uninstalling Java. This is one way of enforcing the policy infrastructure  70 . Deployment Descriptor Dependent actions would include modification of the prerequisite to comply with the policy infrastructure  70 . A check may be made first to see if the action violates a mandatory clause of the deployment descriptor  36 . The software has a Java prerequisite, but Java (Sun/Oracle) is not mandatory, hence the change to XYZ Java throws no exception approval message. Hence, the deployment descriptor  36  can be changed as required by the policy infrastructure  70 , i.e., prerequisite P 1  is modified to check for NO Java or Java (Sun/Oracle) condition and, accordingly, include XYZ Java installable unit. The user can be notified about the actions to be taken. This would help him carry out an impact analysis of the installation. The same evaluation process is carried out for all the Policies that have been retrieved from the repository. 
         [0044]    After the evaluation process is completed, the business compliant deployment descriptor  36  is provided to the installer. Installer will go ahead and install the Business Policy Compliant Solution which would ensure that XYZ Java is used by the solution instead of Java. 
         [0045]    The customer might want to create a table that contains information to guide the install, uninstall and upgrade of software. The table contains information about the following:
   a) Supported configurations of Software (patch level, service pack level, sub components supported etc).   b) Critical Software that must be running at all times (Software that should not be uninstalled).   c) Number of licenses available for all the different types of Software (Installation should be preceded by a check to see if the required licenses are available).   
 
         [0049]    For example, a solution may require a prerequisite Software Y. The customer may want to check the table to see if a license is available for Software Y. This information (Number of available licenses) is listed in the table. The policy infrastructure  70  corresponding to this requirement (Policy  3 ) would require all software to be checked against the table. This can be represented as follows: 
       Prerequisite  1  (P 1 ): Software Y 
       [0050]    The deployment descriptor  36  would have a dependency check as follows: 
       Prerequisite  1  (P 1 ) 
       [0051]      
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 If ( Software Y == not installed) 
               
               
                   
                 {Include installable unit corresponding to Software Y} 
               
               
                   
                   
               
             
          
         
       
     
         [0052]    The prerequisite check needs to look the same, but the table needs to be checked for data related to Software Y. This would qualify as a custom action  62 . This custom action  62  would check the table for information about the number of licenses available for Software Y. If sufficient numbers of licenses are available, then the deployment descriptor  36  is updated to allow installation of Software Y. 
       Custom Action (CA) 
       [0053]    Check the table for information about the number of licenses available for software Y 
       Prerequisite  1  (P 1 ) 
       [0054]      
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 If (( Software Y == not installed)) 
               
               
                   
                 {Include installable unit corresponding to Software Y} 
               
               
                   
                   
               
             
          
         
       
     
         [0055]    The installer (with embedded policy infrastructure  70 ) would install the solution as follows:
   1) The installation is triggered.   2) Deployment descriptor  36  is picked up by the installer.   3) Deployment descriptor  36  is handed over to policy engine  42 .   4) Policy engine  42  picks up relevant Policies (filtered by scope if required) from the Customers Business Policy Repository.   5) Policy  3  is retrieved from the repository and evaluated against the deployment descriptor  36 .   
 
         [0061]    The data from the deployment descriptor  36  (Prerequisites P 1 ) is given as input to the evaluation engine. The policy infrastructure  70  can be interpreted to mean that all software that needs to be installed needs to pass the license check (Custom action). The condition part  72  of the policy infrastructure  70  in this case would comprise of a custom action  62  that checks to see if the required numbers of licenses are available to install the prerequisite. Since the current deployment descriptor  36  has a Software Y dependency, the actuator  60  would be triggered to take the associated action (modify deployment descriptor  36  to allow installation of the prerequisite). 
         [0062]    The actuator  60  can execute two kinds of actions, either Deployment Descriptor Independent actions, or Deployment Descriptor Dependent actions. Deployment Descriptor Independent actions could include reducing the number of licenses available for Software Y in the table by one. Deployment Descriptor Dependent actions would include modification of the prerequisite to comply with the policy infrastructure  70 . In this case, the deployment descriptor  36  does not need to be changed, as the prerequisite remains the same. If the policy infrastructure  70  is not satisfied, the deployment descriptor  36  would have to be changed to remove the installable unit corresponding to Software Y. If Software Y is mandatory and the license condition is not satisfied, then the customer needs to be notified about the dearth of licenses. If Software Y is not mandatory, the deployment descriptor  36  can be changed, as required by the policy infrastructure  70 , i.e., prerequisite P 1  is added or removed from the deployment descriptor  36  based on the evaluation of Policy  3 . The user can be notified about the actions to be taken. This would help him carry out an impact analysis of the installation. The same evaluation process is carried out for all the Policies that have been retrieved from the repository. 
         [0063]    After the evaluation process is completed, the business compliant deployment descriptor  36  is provided to the installer. Installer will go ahead and install the Business Policy Compliant Solution. This policy infrastructure  70  would ensure that all Software installations are preceded by a custom check that verifies the existence of required licenses. 
         [0064]    For example, Business Policy of a company, Policy  1  insists that 50 MB of free disk space must be maintained at all times on any given system. Without the policy infrastructure  70  as disclosed previously in accordance with embodiments of the invention, there would be no way for the company to automatically enforce their policy. They would have to either manually ensure that all systems comply with this policy or buy another solution that takes care of their requirements. This scenario can be handled in an easier manner by using the above-described algorithm. 
         [0065]    For example, a solution Software X has a prerequisite of 150 MB of disk space and min 100 MHz processor. This can be represented as follows:
   Prerequisite  1  (P 1 ): 150 MB of disk space   Prerequisite  2  (P 2 ): Min 100 MHz processor   
 
         [0068]    The deployment descriptor  36  would have a dependency check as follows: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 If ((P1) &amp;&amp; (P2)) 
               
               
                   
                 {Return TRUE to Change Manager indicating that all dependencies 
               
               
                   
                 have been satisfied} 
               
               
                   
                 Else 
               
               
                   
                 {Report an Error} 
               
               
                   
                   
               
             
          
         
       
     
         [0069]    The prerequisite check looks like this: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 If ((Available disk space &gt;= (P1+50MB)) &amp;&amp; (P2)) 
               
               
                   
                 {Return TRUE to Change Manager indicating that all dependencies 
               
               
                   
                 have been satisfied} 
               
               
                   
                 Else 
               
               
                   
                 {Report an Error} 
               
               
                   
                   
               
             
          
         
       
     
         [0070]    The installer (with embedded policy infrastructure  70 ) would install the solution as follows.
   1) The installation is triggered.   2) Deployment descriptor  36  is picked up by the installer.   3) Deployment descriptor  36  is handed over to policy engine  42 .   4) Policy engine  42  picks up relevant Policies (filtered by scope if required) from the Customers Business Policy Repository.   5) Policy  1  is retrieved from the repository and evaluated against the deployment descriptor  36 .   
 
         [0076]    The data from the deployment descriptor  36  (Prerequisites P 1  and P 2 ) is given as input to the evaluation engine. The Policy can be interpreted to mean that all software must ensure that they check for 50 MB of disk space beyond their individual requirements. The condition part  72  of the Policy in this case would check to see if the installation has a disk space prerequisite. Since the current deployment descriptor  36  does have a memory prerequisite, the actuator  60  would be triggered to take the associated action. 
         [0077]    The program could get 50 MB of space allocated to itself and release it after the installation, which is one way of enforcing the Policy. Deployment Descriptor Dependent actions would include modification of the prerequisite to comply with the policy. A check is first made to see if the action violates a mandatory clause of the deployment descriptor  36 . Since the memory prerequisite is not being decreased to below the mandatory level of 150 MB, no exception approval messages are thrown. Hence, the deployment descriptor  36  can be changed as required by the policy, i.e., prerequisite P 1  is modified to check for 150 MB+50 MB of disk space. The user can be notified about the actions to be taken. This would help the user carry out an impact analysis of the installation. The same evaluation process is carried out for all the Policies that have been retrieved from the repository. 
         [0078]    After the evaluation process is completed, the business compliant deployment descriptor  36  is provided to the installer. The installer can go ahead and install the Business Policy Compliant Solution, which would ensure 50 MB of free disk space on the system. 
         [0079]      FIG. 6  depicts a pictorial representation of a collection of data processing systems in which embodiments of the invention may be implemented. System  100  is a network of computers and includes network  102 , which is the medium used to provide communications links between various devices and computers connected together within system  100 . Network  102  may include connections, such as wire, wireless communication links, or fiber optic cables. 
         [0080]    In the depicted example, server  104  is connected to network  102  along with storage unit  106 . In addition, clients  108 ,  110 , and  112  are connected to network  102 . These clients  108 ,  110 , and  112  may be, for example, personal computers or network computers. In the depicted example, server  104  provides data, such as boot files, operating system images, and applications to clients  108 - 112 . Clients  108 ,  110 , and  112  are clients to server  104 . System  100  may include additional servers, clients, and other devices not shown. In the depicted example, system  100  includes the Internet with network  102  representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, system  100  also may be implemented with a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN).  FIG. 6  is intended as an example, and not as an architectural limitation for the present invention. 
         [0081]      FIG. 7  depicts a block diagram of a data processing system that may be implemented as a server, such as server  104  in  FIG. 6 . Data processing system  200  may be a symmetric multiprocessor (SMP) system including a plurality of processors  202  and  204  connected to system bus  206 . Alternatively, a single processor system may be employed. Also connected to system bus  206  is memory controller/cache  208 , which provides an interface to local memory  209 . I/O bus bridge  210  is connected to system bus  206  and provides an interface to I/O bus  212 . Memory controller/cache  208  and I/O bus bridge  210  may be integrated as depicted. 
         [0082]    Peripheral component interconnect (PCI) bus bridge  214  connected to I/O bus  212  provides an interface to PCI local bus  216 . A number of modems may be connected to PCI local bus  216 . Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to clients  108 - 112  in  FIG. 6  may be provided through modem  218  and network adapter  220  connected to PCI local bus  216  through add-in connectors. 
         [0083]    Additional PCI bus bridges  222  and  224  provide interfaces for additional PCI local buses  226  and  228 , from which additional modems or network adapters may be supported. In this manner, data processing system  200  allows connections to multiple network computers. A memory-mapped graphics adapter  230  and hard disk  232  may also be connected to I/O bus  212  as depicted, either directly or indirectly. 
         [0084]    Those of ordinary skill in the art will appreciate that the hardware depicted in  FIG. 7  may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention. 
         [0085]    The data processing system depicted in  FIG. 7  may be, for example, a system running the LINUX operating system (Linux is a trademark of Linus Torvalds in the United States, other countries, or both). 
         [0086]    As will be readily apparent to those skilled in the art, various embodiments of the invention can be realized in hardware, software, or a combination of hardware and software. Any kind of computer/server system(s)—or other apparatus adapted for carrying out the methods described herein—is suited. A typical combination of hardware and software could be a general-purpose computer system with a computer program that, when loaded and executed, carries out the respective methods described herein. Alternatively, a specific use computer, containing specialized hardware for carrying out one or more of the functional tasks of the invention, could be utilized. 
         [0087]    Embodiments or aspects of the invention, can also be embodied in a computer program product, which comprises all the respective features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods. Computer program, software program, program, or software, in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: (a) conversion to another language, code or notation; and/or (b) reproduction in a different material form. 
         [0088]    While it is apparent that embodiments of the invention herein disclosed is well calculated to fulfill the objects stated above, it will be appreciated that numerous modifications and embodiments may be devised by those skilled in the art, and it is intended that the appended claims cover all such modifications and fall within the true spirit and scope of the various embodiments of the invention.