Patent Publication Number: US-9898270-B2

Title: Multi-environment configuration of data integration projects

Description:
RELATED APPLICATION 
     This application is a continuation of U.S. patent application Ser. No. 14/494,345, filed Sep. 23, 2014, entitled “MULTI-ENVIRONMENT CONFIGURATION OF DATA INTEGRATION PROJECTS”, which is a continuation of U.S. patent application Ser. No. 12/816,378, filed Jun. 15, 2010, entitled “MULTI-ENVIRONMENT CONFIGURATION OF DATA INTEGRATION PROJECTS,” now U.S. Pat. No. 8,862,545, issued Oct. 14, 2014. The entirety of this afore-mentioned application is incorporated herein by reference. 
    
    
     BACKGROUND 
     An extract, translate, and load system (ETL) is a computer-based system that extracts data from a specified data source, transforms the data to convert it into a desired state, and loads the transformed data to a specified destination. An ETL system may be used to integrate two subsystems. Transformations may include operations such as reformatting, sorting, filtering, combining data columns, or other types of modifications. 
     A data integration project is a computer-based program or collection of programs that perform ETL operations. Data integration projects often depend on the environment in which they are deployed. The environment includes the data systems to which they connect, receive data, and output data. An environment may include a collection of various software or hardware components, such as computers, computer subsystems, files, tables, addresses, or the like. An environment in which a data integration project executes may change, as a result of deploying the project to a different environment, components of the environment changing, or of other reasons. For example, a data integration project may be tested in a test environment and deployed in a production environment. A project may be deployed in multiple environments. Multiple data integration projects may be executed in a common environment. 
     SUMMARY 
     This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. 
     Briefly, a system, method, and components operate to facilitate execution of one or more data integration projects in one or more environments. In one embodiment, the system includes, for each project, a set of project parameters and a mapping between each project parameter and an environment variable. In one embodiment, the system includes one or more environment representations, each corresponding to an environment. An environment representation may include a set of environment variables, each environment variable of each environment representation having a value. An environment representation may have environment variables in common with other environment representations, though their values may differ across environment representations. Each project may be mapped to a corresponding environment representation. 
     In one embodiment, the system provides, for each project, an environment variable value corresponding to each project parameter. In response to a revision of an environment representation&#39;s environment variable value, each project having a parameter corresponding to the environment representation and environment variable may be provided with the revised value. 
     In some configurations, there may be multiple projects mapped to multiple environment representations, such that an environment representation may have more than one corresponding project. In response to a change of an environment variable, the system may determine each project to be affected, and provide the changed value accordingly. 
     In one embodiment, a project parameter may be specified as an optional parameter. A default value may be specified so that if a corresponding environment variable value is not available, the default value is used as the value of the optional parameter. 
     In one embodiment, an environment representation may have a reference to another environment representation. The environment representation may receive environment variable values from the other environment representation. A hierarchy of environment representations may be used. 
     The system facilitates deploying a project in multiple environments, each of which may be the same or differ from each other. It may also facilitate administering changes to an environment in which a project is deployed. The system may also facilitate multiple projects having a common set of one or more environments, or changes to an environment that is common to multiple projects. 
     To the accomplishment of the foregoing and related ends, certain illustrative aspects of the system are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention may be employed and the present invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following drawings. In the drawings, like reference numerals refer to like parts throughout the various figures unless otherwise specified. 
       To assist in understanding the present invention, reference will be made to the following Detailed Description, which is to be read in association with the accompanying drawings, wherein: 
         FIG. 1  is a block diagram of an example data integration setting in which mechanisms described herein may be deployed; 
         FIG. 2  is a block diagram of example data integration system data that may be configured and used in some embodiments; 
         FIG. 3  is a flow diagram illustrating an example embodiment of a process for facilitating the deployment of a project in an environment; 
         FIG. 4  is a flow diagram illustrating an example embodiment of a process for executing a project; 
         FIG. 5  is a flow diagram illustrating an example embodiment of a process for modifying environments with respect to associated projects; 
         FIGS. 6A-B  are block diagrams illustrating mechanisms in which environment representations may be organized and related to other environment representations; and 
         FIG. 7  is a block diagram showing one embodiment of a computing device, illustrating selected components of a computing device that may be used to perform functions described herein. 
     
    
    
     DETAILED DESCRIPTION 
     Example embodiments of the present invention now will be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific example embodiments by which the invention may be practiced. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Among other things, the present invention may be embodied as methods or devices. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense. 
     Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise. The phrase “in one embodiment” as used herein does not necessarily refer to a previous embodiment, though it may. Furthermore, the phrase “in another embodiment” as used herein does not necessarily refer to a different embodiment, although it may. Thus, various embodiments of the invention may be readily combined, without departing from the scope or spirit of the invention. Similarly, the phrase “in one implementation” as used herein does not necessarily refer to the same implementation, though it may, and techniques of various implementations may be combined. 
     In addition, as used herein, the term “or” is an inclusive “or” operator, and is equivalent to the term “and/or,” unless the context clearly dictates otherwise. The term “based on” is not exclusive and allows for being based on additional factors not described, unless the context clearly dictates otherwise. In addition, throughout the specification, the meaning of “a,” “an,” and “the” include plural references. The meaning of “in” includes “in” and “on.” 
     The components described herein may execute from various computer-readable media having various data structures thereon. The components may communicate via local or remote processes such as in accordance with a signal having one or more data packets (e.g. data from one component interacting with another component in a local system, distributed system, or across a network such as the Internet with other systems via the signal). Software components may be stored, for example, on non-transitory computer-readable storage media including, but not limited to, an application specific integrated circuit (ASIC), compact disk (CD), digital versatile disk (DVD), random access memory (RAM), read only memory (ROM), floppy disk, hard disk, electrically erasable programmable read only memory (EEPROM), flash memory, or a memory stick in accordance with embodiments of the present invention. 
     The term computer-readable media as used herein includes both non-transitory storage media and communications media. Communications media typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information-delivery media. By way of example, and not limitation, communications media include wired media, such as wired networks and direct-wired connections, and wireless media such as acoustic, radio, infrared, and other wireless media. 
       FIG. 1  is a block diagram of an example data integration scenario  100  in which mechanisms described herein may be deployed. Embodiments may be deployed in a variety of scenarios; scenario  100  provides one such example. Scenario  100  may be a portion of a larger data integration setting. 
     As illustrated, scenario  100  includes two environments: environment A  102  and environment B  104 . Each of environment A  102  and environment B  104  includes a set of physical or virtual environment components. Examples of environment components are computers, computer systems or subsystems, computer components, people, data stores, tables, threads, files, service access names or passwords, names of arguments for connecting to a database, various computing resources, or the like. Some components may be specifications that control the operation of a project. Examples of behavioral components are specifications of a number of tests to run, an amount of logging to perform, a maximum number of executable programs to use, or a maximum number of threads or processors to use. Some example components are illustrated, such as source computers  106 , destination computers  108 , database  114 , data tables  110 , and administrators  112 . Any one or more of these components may differ between environment A  102  and environment B  104 . Two environments may differ in one or more components, and may share any number of components. For example, a first environment may differ from a second environment only in a number of threads that are allowed to be used by a project. 
     In the example scenario  100 , environment A  102  and environment B  104  each have a corresponding environment representation  116  and  118 , respectively. Environment representations are discussed in further detail herein. Briefly, each environment representation contains data that indicates or represents a specific environment component or feature of the corresponding environment. Examples of such data include names, addresses, capacities, passwords, or the like. In one configuration, environment A  102  and environment B  104  are two environments that exist concurrently. In one configuration, environment A  102  and environment B may be different versions of an environment, existing in different time periods. 
     Example scenario  100  includes projects  120 ,  122 , and  124 . Each of these may be a data integration project, though in some settings other types of computer-based projects may be used. Each project may be associated with one or more environment representations. In the example scenario  100 , project  120  is associated with environment representation  116 ; project  122  is associated with environment representations  116  and  118 ; project  124  is associated with environment representation  118 . Each representation may be concurrent or sequential. For example, instances of project  122  may be associated with environment representations  116  and  118  concurrently, or may be first associated with one, and then the other environment representation. 
     As illustrated in example scenario  100 , there may be various configurations of many-to-many associations between projects and environments. In the illustrated example, environment A  102  has two associated projects  120  and  122 ; environment B  104  has two associated projects  122  and  124 ; project  122  has two associated environments, and each of projects  120  and  124  have one associated environments: environment A  102  and environment B  104 , respectively. Associations between projects and environments may be dynamic. Thus, at a different point in time, the associations of projects  120 ,  122 , and  124  may differ. 
     In one embodiment, each of environment representation  116  and  118  may have a collection of data  126  and  128 , respectively, which corresponds to environment components. In one embodiment, each of projects  120 ,  122 , and  124  may have configuration data respectively, which correspond to environment components accessed or employed by each project. Examples of environment representation data and project configuration data are illustrated in  FIG. 2  and discussed herein. 
       FIG. 2  is a block diagram of example data integration system data  200  that may be configured and used in some embodiments. The illustrated example system data  200  includes project A configuration data  210  and project B configuration data  220 . Each of these examples of configuration data may correspond to a data integration project, such as projects  120 ,  122 , or  124  or  FIG. 1 . In one implementation, project configuration data, or a portion thereof may be represented as a data table. In various implementations, the configuration data may be stored as a table or in another manner. For illustrative purposes, the configuration data is referred to herein as a table, in which each row represents a data item. Each data item of the project configuration data is referred to as a project parameter. 
     Project A configuration data  210  includes a number of fields for each parameter, represented as columns herein. Thus, object field  212  indicates a type of object that the parameter refers to. In the example table of project A configuration data  210 , each parameter has a field of “Project,” though other types of objects may be used, such as a sub-project. 
     Name field  214  indicates a name of each parameter. This may be a name that is used internally by the project, or may be descriptive for view by users such as an administrator. Type field  216  indicates an expected type of each parameter. Types may be an identification of any type used by the project, such as string, integer, real, or more specific data types. In some embodiments, a type may be an aggregate type, such as a collection or list of strings or integer values. In one embodiment, a type may specify an object type, and corresponding values may be objects or references to objects. 
     The value/reference field  218  may indicate a value or a reference to an environment variable that specifies a value. In one embodiment, a “@” character or another character indicates that the field content is a reference to an environment variable, though some implementations may use other mechanisms. In some implementations, all items in this field may be references, so that an indication of a reference is not used. In some implementations, a mechanisms may be used to indicate a value, and omission of the mechanism may indicate a reference. 
     Project B configuration data  220  includes fields: object field  222 , name field  224 , type field  226 , and value/reference field  228 . Each of these fields corresponds to like-named fields as described for project A configuration data  210 . 
     Though not illustrated, additional information may be associated with each parameter of project A configuration data  210  or project B configuration data  220 . For example, a field may include a description of each parameter, or other information to facilitate use of the table. A default-value field may specify a value of a parameter to be used by the project in the event that there is not a binding with an environment variable, or the corresponding environment variable does not have a valid value. In one embodiment, a specification in a default-value field indicates that the corresponding parameter is optional. 
     In the example of  FIG. 2 , each of test environment representation  230  and production environment representation  240  may correspond to an environment representation such as environment representation  116  or  118 . Test environment representation  230  or production environment representation  240  may include collection of data  126  or  128 , or a portion thereof. In some implementations, this data may be implemented as a table or in another manner. For illustrative purposes, the environment representation data is referred to herein as a table, in which each row represents an environment data item, referred to herein as an environment variable. 
     Name fields  232  and  242  indicate a name of each environment variable. Value fields  234  and  244  indicate a value of each environment variable. The value may be a string, integer, real, or any type. Though not illustrated in  FIG. 2 , additional columns may indicate an environment variable type, a description, or other information to facilitate use of the table. 
     In one implementation, each parameter of a project configuration table may have a corresponding environment variable to which it is bound. In one embodiment, a binding is indicated by inserting a name of an environment variable in the value/reference field of a project configuration parameter. In the example of  FIG. 2 , parameter “SourceServer” is bound to environment variable “ERP_System”; parameter “DestServer” is bound to environment variable “DW_System”; and parameter “SendNotifyTo” is bound to environment variable “Admin_Email.” As examples of parameters, “SourceServer” may indicate an identifier or address of a data source; “DestServer” may indicate an identifier or address of a destination server; “SendNotifyTo” may indicate an email or messaging address of an administrator. Parameter “MaxExes” does not have corresponding environment variables. Instead, it has a value of 5 included in the value/reference field. 
     Project B configuration data  220  has similar parameters, though with different names. Thus, “ERP_Source,” “Output,” and “SendNotifyTo” are similar to “SourceServer,” “DestServer,” and “SendNotifyTo,” respectively. These parameters are similarly bound to the environment variables “ERP_System,” “DW_System,” and “Admin_Email,” respectively. The parameter “Log_Data” has a corresponding environment variable of “Log_Level” in the example of  FIG. 2 . 
     In the illustrated example of  FIG. 2 , project A is associated with test environment and production environment. When deployed with test environment, the values corresponding to each environment variable in test environment representation  230  become the values corresponding to each project parameter that is bound to the environment variable. Thus, parameter “SourceServer,” which is bound to environment variable “ERP_System” will have a value of “Test_ERP.” Similarly, the parameter “DestServer” will have a value of “Test_DW. The parameter “SendNotifyTo” will have a value of “Joe@exampl.com. In some configurations, different environments may have zero, one, or more environment variable values that differ from other environments. 
     Production environment representation  240  has environment variables in common with those of test environment representation  230 , though the corresponding values may differ. In the example, each of the environment variables of production environment representation  240  has a different value than the corresponding values of test environment representation  230  that are in common with production environment representation  240 . An environment variable may be identified by its name. Therefore, environment variables in multiple environment representations having the same name are said to match each other. The environment representations are said to have environment variables in common with each other. In the examples of  FIG. 2 , all of the illustrated environment variables of each environment representation match corresponding environment variables in the other environment representation. All of these environment variables are said to be in common with each example environment representation. As illustrated, environment variables in common with multiple environment representations may have different values in each environment representation. 
     When an instance of project A is deployed in the test environment, it therefore uses the set of values illustrated in test environment representation  230 . When an instance of project A is deployed in the production environment, it uses the set of values illustrated in production environment representation  240 . Thus, the project&#39;s configuration is automatically modified for the environment in which it is deployed. 
     In the illustrated example of  FIG. 2 , project B is also associated with test environment and production environment. When deployed with each of these environments, the value of each environment variable is used for the corresponding project parameter that is bound to the environment variable, though the set of parameters may differ from that of project A. Specifically, project B includes a parameter “Log_Data” that is bound to the environment variable “Log_Level” and receives an integer value. 
     Project A and project B may both be deployed in the production environment. In some situations, a value of one or more environment variables may change. For example, an administrator&#39;s email address may change, or the name of the ERP system may change, or a password may change. An administrator may change the value of the environment variable to reflect or create the change. In response, the system may automatically change the values of the corresponding parameters in both project A and project B. In some implementations, a change to each project is not needed in order to accommodate the environment change. In some configurations, one or more components of a project may be rebooted, reinitialized, or otherwise prepared for a change of environment. In some configurations, a project may dynamically adjust to the modified environment while continuing to execute. 
     The set of parameters listed and described in each of project A configuration data  210  and project B configuration data  220  may be considered to be a project contract. A project contract defines a set of configurable parameters exposed by the project. It may facilitate deployment of execution of a project by providing a mechanism for an administrator to bind the project to the environment. A project contract may enable a system to determine whether a project is sufficiently bound to its environment. In some situations, a project contract may facilitate debugging or other analysis of a project or an environment by explicitly indicating the bindings of the project, as well as the bindings of the environment. For example, an administrator desiring to modify an environment may use the set of project contracts to determine how the change may affect projects bound to the environment. 
       FIG. 3  is a flow diagram illustrating an example embodiment of a process  300  for facilitating the deployment of a project in an environment. The illustrated portions of process  300  may be initiated at block  302 , where a set of project parameters is created. In some embodiments, this action may be performed by a developer of the project. Project A configuration data  210  and project B configuration data  220  illustrate examples of sets of project parameters. 
     The process may flow to block  304 , where an environment representation is created. In some embodiments, this action may be performed by a system administrator. An environment representation may include a set of environment variables that correspond to components of the environment. Test environment representation  230  and production environment representation  240  illustrate examples of environment representations. 
     The process may flow to block  306 , where values for each environment variable may be provided. In some implementations, this may include storing a value in a table or other structure, such that a value is stored corresponding to each environment variable. In some implementations, an external process may set values for some environment variables. 
     The process may flow to block  308 , where project parameters are mapped to environment variables. In the example illustrated by  FIG. 2 , this action may include storing an environment variable name corresponding to each project parameter. 
     The process may flow to block  310 , where the project is mapped to an environment representation, such as test environment representation  230  or production environment representation  240  of  FIG. 2 . The association between a project and an environment representation defines the environment to which the project is associated. 
     The process may flow to done block  312 , and exit or return to a calling program. 
       FIG. 4  is a flow diagram illustrating an example embodiment of a process  400  for executing a project. Process  400  may be performed subsequent to or concurrently with process  300  or a portion thereof. The illustrated portions of process  400  may be initiated at block  402 , where the project is deployed in an environment. This action may include one or more of a variety of actions, such as installing files or performing other configuration actions. In some configurations, the project may already be deployed, and the actions of block  402  may be omitted from process  300 . 
     The process may flow to block  404 , where the system may receive the project to environment representation mapping. This may be the mapping specified in  310  of  FIG. 3 . The process may flow to block  406 , where the project is executed. In some configurations, this may include initializing the project. In some configurations, the project may have already been initialized. 
     The process may flow to block  408 , where environment variable values corresponding to project parameters may be provided to the project. This may be performed in response to one or more requests from the project, or the values may be delivered to the project in another manner. The actions of block  408  may include retrieving the values bound to each environment variable and providing each value for a corresponding project parameter. The process may flow to done block  410 , and exit or return to a calling program. 
     In some configurations, one or more of the actions of processes  300  or  400  may be omitted. For example, in some configurations, some of the actions may have been previously performed. In some implementations, the ordering of actions described herein may vary, or be performed concurrently. As discussed, a system may support multiple projects in an environment. Thus, processes  300  or  400  may be performed sequentially or concurrently with respect to multiple projects. 
       FIG. 5  is a flow diagram illustrating an example embodiment of a process  500  for modifying environments with respect to associated projects. In some configurations, process  500  may be performed after process  300  or  400 , or combined with process  300  or  400 . The illustrated portions of process  500  may be initiated at block  502 , where one or more projects deployed in an environment may be received. Receiving a project may include receiving an identifier, link, program code, or other data that corresponds to a project. Projects  120  and  122  of  FIG. 1  are examples of projects that are deployed in and associated with environment A  102  of  FIG. 1 . 
     The process may flow to block  504 , where an environment representation corresponding to the associated project is modified. Modification may include modifying one or more environment variable values of a representation. Modification may include modifying the mapping between a project and an environment representation so that the project maps to a different environment representation. A result of the action of block  504  is that the project&#39;s view of the environment is modified. 
     The process may flow to loop  506 , which iterates for each project affected by the change of block  504 . This may include each project that is mapped to the environment representation resulting from block  504 . Thus, in one configuration, this may be a set of projects which have had mappings to environment representations changed as a result of block  504 . In the illustrated embodiment, loop  506  includes blocks  508  and  510 , and is terminated by block  512 . Within each iteration of loop  506 , a project being processed is referred to as the “current” project. 
     The process may flow to block  508 , where the current project may be reinstalled. This action may be omitted in some configurations. It may occur, for example, in a configuration in which a change in environment includes changing a computing device upon which the project, or a portion thereof, is being executed. 
     The process may flow to block  510 , where the current project may be continued or re-executed in the modified environment. Re-executing a project may be selectively performed based on the type of environment changes that have been made, logic of the project, or a current status of the project. In some configurations, the current project may continue executing from its current state, revert to a prior state, perform some initialization actions, or otherwise continue without being re-executed from an initial state. 
     The process may flow to block  512 , and selectively perform another iteration of loop  506 , based on whether there is another project to be processed. Upon exiting loop  506 , the process may flow to done block  514 . 
       FIGS. 6A-B  are block diagrams illustrating mechanisms in which environment representations may be organized and related to other environment representations.  FIG. 6A  includes example configuration  600  with environment representations  602  and  606 , each of which includes link  608  or  610 , respectively. The link refers to environment representation  604 . In one embodiment, a system may consider environment representation  604  to be included within each of environment representations  602  and  606 . An environment representation may include zero, one, or more links, and linked environment representations may include links of other environment representations, forming a directed graph of linked environment representations. 
       FIG. 6B  includes example configuration  618  with environment representation objects  622  and  624 , each of which is a child of environment representation object  620 . Each child environment representation object may inherit environment variables or values of environment variables from a parent or ancestor object. In some implementations, a child object may add new environment variables or override values of inherited environment variables. In some implementations, a child object may inherit qualities from multiple parent objects. In an example of a hierarchical structure, a parent environment representation object may correspond to a generic test environment; child environment representation objects may correspond to variations of the generic test environment. 
     In embodiments that provide mechanisms for a hierarchical structure or linking of environment representations, a change to an environment representation, such as environment representation  604  or environment representation object  620 , may affect each project that is associated with it, directly or indirectly. Process  500  may include determining the various projects that are affected by an environment representation change, and iterating loop  506  for each one. 
       FIG. 7  is a block diagram showing one embodiment of a computing device  700 , illustrating selected components of a computing device that may be used to implement mechanisms described herein, including processes  300 ,  400 , or  500 . Computing device  700  may include many more components than those shown, or may include less than all of those illustrated. Computing device  700  may be a standalone computing device or part of an integrated system, such as a blade in a chassis with one or more blades. 
     As illustrated, computing device  700  includes one or more processors  702 , which perform actions to execute instructions of various computer programs. In one configuration, each processor  702  may include one or more central processing units, one or more processor cores, one or more ASICs, cache memory, or other hardware processing components and related program logic. As illustrated, computing device  700  includes an operating system  704 . Operating system  704  may be a general purpose or special purpose operating system. The Windows® family of operating systems, by Microsoft Corporation, of Redmond, Wash., are examples of operating systems that may execute on computing device  700 . 
     Memory and storage  706  may include one or more of a variety of types of non-transitory computer storage media, including volatile or non-volatile memory, RAM, ROM, solid-state memory, disk drives, optical storage, or any other medium that can be used to store digital information. 
     Memory and storage  706  may store one or more components described herein or other components. In one embodiment, memory and storage  706  stores a collection of environment representations  720  and project repository  722 . Project repository  722  may include one or more projects, such as project  120 ,  122 , or  124  of  FIG. 1 . In one embodiment, memory and storage  706  stores environment manager  724 . Environment manager  724  may include program instructions, executable by a processor, that implement at least a portion of the mechanisms described herein, including processes  300 ,  400 , or  500 . Environment manager  724  may, for example, retrieve values of environment variables associated with an environment representation and provide the values corresponding to each project parameter to each project that defines the parameter and is mapped to the environment representation. Environment manager  724  may, in response to an environment change, determine projects that are affected by the change and facilitate each project using the modified components of the environment. 
     Environment manager  724 , environment representations  720 , and project repository  722  are components of a system  730  that may implement mechanisms described herein. Any one or more of these components may be moved to different locations in RAM, non-volatile memory, or between RAM and non-volatile memory by operating system  704  or other components. In some configurations, these components may be distributed among one or more computing devices. In one embodiment, one or more computing devices  700  each including system  730  or a portion thereof may form a computing system for facilitating execution of one or more data integration projects in multiple environments or an environment that undergoes changes. 
     Computing device  700  may include a video display adapter  712  that facilitates display of program code or other information to a user. Though not illustrated in  FIG. 7 , computing device  700  may include a basic input/output system (BIOS), and associated components. Computing device  700  may also include a network interface unit  710  for communicating with a network. Software components, such as those stored in memory and storage  706 , may be received via transitory media and network interface unit  710 . Computing device  700  may include one or more display monitors  714 . Embodiments of computing device  700  may include one or more input devices  716 , such as a keyboard, pointing device, audio component, microphone, voice recognition component, or other input/output mechanisms. 
     It will be understood that each block of the flowchart illustration of  FIGS. 3-5 , and combinations of blocks in the flowchart illustration, can be implemented by software instructions. These program instructions may be provided to a processor to produce a machine, such that the instructions, which execute on the processor, create means for implementing the actions specified in the flowchart block or blocks. The software instructions may be executed by a processor to provide steps for implementing the actions specified in the flowchart block or blocks. In addition, one or more blocks or combinations of blocks in the flowchart illustrations may also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the invention. 
     The above specification, examples, and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.