Patent Application
20080040455
The claimed subject matter is described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the subject innovation. It may be evident, however, that the claimed subject matter may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the subject innovation.
As utilized herein, terms “component,” “system,” “interface,” “wizard,” “device,” “engine,” “console,” “generator,” “collector,” and the like are intended to refer to a computer-related entity, either hardware, software (e.g., in execution), and/or firmware. For example, a component can be a process running on a processor, a processor, an object, an executable, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and a component can be localized on one computer and/or distributed between two or more computers.
Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick, key drive . . . ). Additionally it should be appreciated that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a local area network (LAN). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter. Moreover, the word “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs.
Now turning to the figures,
The automatic software deployment component 102 can efficiently automatically deploy any suitable software in the distributed network 106 utilizing the collected data specific to the target environment (e.g. the distribute environment 106 that data is collected from). Thus, rather than conventionally having a user manually type and/or enter information necessary for software deployment, the inventory collection component 104 can retrieve deployment-necessary data to allow the automatic software deployment component 102 to deploy such software with little or no user intervention. Moreover, the inventory collection component 104 can provide any suitable data related to the distributed network 106 that can mitigate installation and/or deployment of software. For example, based on the physical topology of the distributed network 106, the automatic software deployment component 102 can implement parallel deployment such that particular steps and/or processes are employed in a specific order/sequence. Moreover, such steps and/or processes can be any suitable steps and/or processes related to deploying software within the distributed network 106 (e.g., file installation, user account setup, approvals, upgrades, license agreements, changing of installation compact discs, etc.). In other words, rather than a sequential and/or step-by-step process for software deployment in a distributed network, the software deployment can be in parallel, wherein multiple steps are done simultaneously so as to efficiently deploy such software and significantly decreasing deployment time.
It is to be appreciated that the utilization of the terminology “deploy software” is not limited to a deployment task nor does it have to be exclusive to software. For instance, the deploy software can be targeted at a change management activity, a decommissioning an entity and/or device, etc. Moreover, a task is not exclusive to software. For example, manual tasks such as changing compact discs (CD's) related to installation can be handled in the process. In addition, software related goals that are manual tasks such as confirming legal licenses can be initiated (e.g., which may only be manifest in a piece of paper). In still another example, a task can also be coordinated across a range of resources that are not limited to hardware/software/service. In particular, several people can be given concurrent tasks and until they confirmed independent completion of them, other downstream tasks with prior dependencies upon those tasks may not be started.
In one aspect in accordance with the subject innovation, various reports can be generated and/or provided related to the automatic deployment of the software in the distributed network 106. For example, a report can be generated based on the collected data associated with the distributed network (e.g., collected via the inventory collection component 104) to illustrate the various data, settings, configurations, devices, etc. within and/or about the distributed network 106. In another example, a report can be provided that illustrates a proposal for a particular distributed network and/or environment. In yet another example, a report can be provided that relates to a proposed deployment strategy of the software based on particular settings. In still another example, a report can be generated to provide data related to the complete installation and/or deployment of the software (e.g., final software settings, data associated with deployment, security related data, etc.). It is to be appreciated that a plurality of reports and/or data can be generated by the system 100 (discussed infra) and the above are examples and are not to be limiting on the claimed subject matter.
In another aspect in accordance with the claimed subject matter, the automatic software deployment component 102 can employ verification techniques to ensure accurate deployment of software. For instance, the deployment steps and/or process can be verified before subsequent steps and/or procedures are taken to progress the deployment of the software in the distributed network. In particular, the system 100 can halt deployment of the software when, for instance, verification is not received and/or an error occurs (discussed infra). Thus, the system 100 can ensure accurate deployment of the software based at least in part upon verifying deployment.
Moreover, the system 100 can include any suitable and/or necessary interface component (not shown and herein referred to as “interface”), which provides various adapters, connectors, channels, communication paths, etc. to integrate the automatic software deployment component 102 into virtually any operating and/or database system(s). In addition, the interface can provide various adapters, connectors, channels, communication paths, etc., that provide for interaction with the automatic software deployment component 102, inventory collection component 104, distributed network 106, and any other device and/or component associated with the system 100.
The system 200 can further include a data store 202 that can include any suitable data related to the distributed network 106, inventory collection component 104, the automatic software deployment component 102, etc. For example, the data store 202 can be a SQL data store that can include, but not limited to including, configuration data, proposal information, project status, operating system information, application compatibility, Meta data, preferences, hardware inventory, software inventory, plan information, tasks, and/or any other suitable data related to the deployment of software within the distributed network 106. In one example, inventory data can be stored in the data store 202 (e.g., a SQL Server or MSDE database) on a laptop or installed on a server on a customer's network. If the user has multiple customers, the information about each customer can be stored in a separate data store 202 and/or database (e.g., providing the ability to store and act on separate compartmentalized projects). The information stored in each database includes Meta data that describes upgrade rules, operating system information such as version and registered user, hardware/software inventory, configuration information and application compatibility data. The Proposal information can be added at a later time, while the project status can be automatically updated as the work is performed.
It is to be appreciated that the data store 202 can be, for example, either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of illustration, and not limitation, nonvolatile memory can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). The data store 202 of the subject systems and methods is intended to comprise, without being limited to, these and any other suitable types of memory. In addition, it is to be appreciated that the data store 202 can be a server, a database, a hard drive, and the like.
The automatic software deployment component 102 can include a workflow engine 302, wherein the workflow engine 302 is a model-based transaction-oriented workflow engine that allows flexible deployment and configuration of applications and related components on multiple machines in a distributed networked environment. At the heart of the system 300 is a model-driven, transaction-oriented workflow engine 302. The elements which define and orchestrate the behavior, as well as describe the state of the workflow engine 302 can be modeled and represented as relational entities and stored in the data store 202 (e.g., a SQL database). More specifically, a workflow graph describing possible workflow execution paths required to deploy the desired set of software components can be modeled and encoded at a Meta-level, and is defined in terms of sets of precedence constraints, priorities and desired configuration states.
The system 300 can define a domain-specific model for deploying and configuring server applications, an application associated with directory services, messaging systems, electronic messaging systems, operating systems, server monitoring software and/or applications, and the like. The precedence constraints in the model define the order that tasks can be executed in. The use of precedence constraints enables multiple steps to be executed in parallel which, in turn, serves to reduce the total time for deployment. Because state changes are transacted, and tasks are executed based on declared precedence constraints, the model is an inherently scalable, consistent and fault tolerant solution to coordinating long running processes. Additionally, because models are declarative in nature, they are completely independent of the physical topology that the components are to be deployed to. This allows the end user to choose which services will be co-located or installed on dedicated systems. It is to be appreciated that any arbitrary collection of software components can be represented and deployed using the meta-level model-based approach associated with the system 300.
The following sections describe the core concepts around which the workflow modeling process can be constructed. The task sequence, or workflow, consists of an arbitrary number of steps. The steps can control the flow of execution and identify what task should be executed. Each step is executed whenever all of its precedence constraints have been satisfied. Thus, this approach provides an inherently parallel execution model. Any steps that have satisfied the precedence constraints can automatically be executed in parallel to reduce the total execution time.
Each step in a workflow can have zero or more precedence constraints. The set of precedence constraints associated with a given step defines the necessary and sufficient state conditions required for the step to execute. When a step is executed it has an execution status of “NotRun”, “Running”, “Success”, “Failure” or “Completed.” “NotRun” means that the step has not yet been executed. “Running” indicates the step is currently executing, and its execution completion status is currently unknown. “Success” indicates that the step has completed execution successfully based upon process exit code. “Failure” indicates that the step failed for any reason and is indicated by a non-zero exit code. “Completed” can indicate an execution has occurred regardless if such execution is a “Success” or a “Failure.”
Each precedence constraint can also define the required execution status of its predecessor step. For example, a workflow can be defined where Task A has no precedence constraints and is therefore eligible for immediate execution. Task B has a precedence constraint that requires that Task A be completed with an execution status of “Success.” Task C has a precedence constraint that requires that Task A be completed with an execution status of “Failure.” Complex constraints can be created from a combination of “Success”, “Failure” and “Completion” statuses.
While Steps control the flow of execution, Tasks describe what to execute. Each Task, for instance, can be implemented as either a Process, Batch File, SQL Server stored procedure or manual operation. The return code from the task can define the execution status for the step that a given task is associated with. Tasks can optionally define a compensation command (e.g., compensatory action) that is implicitly executed upon failure. The user can provide the status code of manual operations.
For instance, a task often utilizes parameters that can define a file path/name, server, user name or password. A task can have one or more parameters associated with it that are stored in the database. Parameters values can be communicated and shared between Tasks. This allows the output filename for Task A to be used as the input filename for Task B.
A workflow can be executed many times. Each execution of a workflow is persisted in the data store 202 (e.g., a SQL database in a Workflow executions table). This summarizes the overall status of the workflow. Detailed information about the execution of each step/task can be stored in a WorkflowStepExecutions table. Whenever a task completes execution, a stored procedure updates the state in the WorkFlowStepExecutions table. A SQL Server trigger on this table can query the WorkflowStepExecutions table to identify and execute any other steps that have all of their precedence constraints satisfied. If the workflow is completed, it can write the final status to the Workflow executions table. Collectively, the concepts described above can be organized logically as depicted in an entity-relation model (e.g., refer to
The system 400 can further include a report generator 404 that can generate any suitable report and/or documentation related to the software deployment, the distributed network 106, and/or the system 400. For example, various documents, graphs, charts, presentations, graphics, emails, web pages, and/or other visual materials can be provided by the report generator 404. For instance, such documentation and/or reports can facilitate allowing a user to view at least one of a particular deployment strategy, a current status of the distributed network, a proposal for software deployment, a summary on the software deployment, etc. For instance, a distributed network can be evaluated such that a report can be generated that provides the current status of the distributed network. In particular, the report and/or documentation generated can be utilized to evaluate the current security, integrity, composition, and/or topology of the distributed network, wherein the report and/or documentation can provide in-depth guidance to providing advice related to the distributed network. In other words, a report can allow a user to identify particular problems and/or issues related to security, integrity, composition, and/or topology which may not have been identified albeit for the report.
Specifically, the report can include any suitable data related to the distributed network 106 and/or deployment of software. The reports and/or documents can be a word processing document, a graph, a picture, a chart, an illustration, and/or any combination thereof, etc. The report generator 402 can provide the report via email 406, paper documents 408, HTML, a website, text messages, and/or any other techniques associated with displaying and/or receiving data. For example, a report can be generated and sent to an email address providing information related to, but not limited to, the distributed network and/or deploying software in the distributed network. In addition, the report can be generated and then distributed to various entities, targets, users, developers, testers, systems, components, databases, etc. (discussed infra)
The system 400 can further include a log component (not shown) that can log various data associated with the system 400. For instance, the log component can log data such as, but not limited to, configurations/settings of the distributed network 106, devices within the distributed network 106, IP addresses, DNS server names, network names, software installed and/or deployed, user profiles, deployment settings, deployment progress, proposals, summaries, hardware and/or software topology, deployment sequence, computer names, any suitable data related to the system 400, etc.
Moreover, the system 500 includes a mechanism to define, store, and evaluate graphs utilizing a relational model that has been translated and encoded as a relational database schema. This model, which can be also referred to as a meta-model, can describe any arbitrary software deployment workflow. The system 500 is an innovative mechanism to evaluate all possible workflow nodes eligible for execution utilizing a complex relational query. The result setoff this query can return all workflow nodes which can be eligible for execution. Moreover, the precedence constraints (discussed below) in the model can define the order that a task can be executed. By implementing the precedence constraints, multiple steps can be executed in parallel which can reduce the total time for software deployment. The model is also a declarative model which can provide the separation between the physical topology and the software components that are being deployed. This can allow an end user to choose which services will be co-located or installed on dedicated systems. The system 500 provides a complete model of the software components to be deployed and represented in terms of precedence constraints, priorities, and desired configuration states. These entities are organized into a workflow graph which can describe all possible execution paths required to deploy said software components in the distributed networked environment. For instance, any suitable acyclic graph can be utilized to evaluate the particular inventory of a distributed network to ascertain the opportunities for parallel installation and/or deployment. In addition, the model-based approach accommodates the execution of both idempotent and non-idempotent tasks (e.g., the property of idempotency can mean that repeated executions to a task has the same effect as one execution of the task), which can provide greater flexibility to users in the creation of models.
The system 500 can include the data store 202 (e.g., a SQL Server database), an inventory wizard 502, the inventory collector 104, a project proposal wizard 504, detailed project plan 506, diagrams, task check lists and automation 510.
For example, a user can plug a laptop into the network or install an Inventory, Assessment & Proposal Tool on a machine on the network. The user can run the Inventory Wizard 502 to quickly specify the information the user would like to collect. The user can choose the default which uses LAN Manager, Active Directory, WMI and SNMP to collect hardware and software information associated with the inventory collector 104, which can give a detailed understanding of all of the assets installed in this environment.
The inventory data is stored in the data store 202 (e.g., a SQL Server or MSDE database) on a laptop or installed on a server on the customer's network. The information about each customer can also be stored in a separate database. The information stored in each database includes Meta data that describes upgrade rules, operating system information such as version and registered user, hardware/software inventory, configuration information and application compatibility data. The Proposal information can be added later, while the project status can be automatically updated as the work is performed.
It is to be appreciated that the inventory collector 104 can provide any suitable data associated with the distributed network having devices, such as, but not limited to, a router 514, a workstation 516, a server 518, a computer 520, a laptop 522, a wireless access point 524, a tablet PC 526, a pocket PC 528, and a printer 530.
The inventory collector 104 can include a Unicode inventory collector, which can be a C# program running on the user machine that collects detailed information using Win32, WMI, Active Directory, service control manager, DNS, OSPF (open shortest path first), and SNMP. The data to be collected is specified using the Inventory Wizard 502 and stored in the SQL Server database (e.g., data store 202). It remotely connects to each machine using RPC, DCOM, LDAP or any other suitable protocols (e.g., HTTP, web services, WSmanagement, WMI, etc.). The Unicode Inventory collector reads the data stored in the SQL Server database, executes each of collectors and inserts the data into the SQL Server inventory database.
In a particular example, some platforms may not be compatible with certain protocols and/or legacy platforms may not provide the capabilities of network connectivity (e.g. legacy operating systems which do not suport RPC, DCOM or directory services, etc.). In other words, such higher level protocols may not be utilized and an agent can be deployed, wherein such agent can create a file and employ SMB (server message blocks) for file sharing. In paticualr, legacy platforms may not support RPC, DCOM or WMI. If inventory information is required for these machines, a C++ Legacy Collector must be deployed on each machine and a central file share created. This collector only returns a subset of information using Win32 and the registry. The data can be written to a network share where it is imported into the inventory database.
The inventory collector 104 can also utilize a Win32 collector. Using the Win32 API NetServerEnum( ), Windows servers, workstations and laptops are identified on the network. Win32 APIs are used to check for Active Directory, Domains and clustering. Information is read from the registry using the standard APIs. In addition, some network configuration information is read from DNS, DHCP and WINS.
The inventory collector 104 can further include a Windows Management Instrumentation (WMI) collector. The collector uses WMI to get detailed hardware and software inventory and OS configuration information from each machine it has permissions on. This includes information about local accounts, BIOS, disk drives, memory, processor information, software inventory, network configuration and QFEs.
An active directory collector can also be implemented by the inventory collector 104. LDAP queries are executed against Active Directory if present. Queries against the Active Directory User object are used to retrieve information such as the user's name, address, phone number, location and manager. In addition, the computer object is used to identify servers, workstations, domain controllers and global catalogs.
In yet another example, the inventory collector 104 can further include a simple network management protocol (SNMP) collector for network devices. The SNMP collector is used to identify IP addressable network devices such as routers, switches, and fire walls using standard SNMP MIBS.
If an internet connection is available, the system 500 can check for updates to the application compatibility database 532 using the Application Compatibility Toolkit (ACT 4.0) via the Internet 512. If no connection is available, the system can utilize the version current at the time of the product is made available to the public.
The Project Proposal Wizard 504 lets the user decide what type of work should be included as part of this bid. It could include upgrading NT4 Domains to Active Directory, Upgrading Exchange 5.5 to Exchange 2003, NT Server 4 to Windows Server 2003, ISA and upgrading client workstations to Windows XP using BDD. It is to be appreciated that the above examples are not to be limiting on the subject innovation and that any upgrading for software can be included. The final result is a detailed draft proposal that the partner can give to the customer for consideration.
The detailed project plan 506 is designed to reduce the time on-site required by the user. It will also enhance the user's reputation by allowing to proactively identify known compatibility problems and recommended remediation before the upgrade/migration begins.
The detailed inventory and proposal information in the database is used to automatically generate professional diagrams, checklists and automation 508 that summarize both the current and proposed architecture. These diagrams make it easy for both the user and the customer to understand exactly what has been deployed in production. It automatically recommends specific deployment topologies based on the customer's environment and recommends how to most efficiently reuse existing IT assets. It also includes detailed check lists that can be used by less experienced consultants on the partner's staff. Finally, unattended setup scripts (SIF files, Response Docs, etc) are generated to reduce the time to install and configure the network, messaging and management servers. It also automatically generates verification steps before and after each task in the deployment task sequence. In addition, the system 500 can include a SQL server reporting service 510 can be provided.
It is to be understood that the intelligent component 602 can provide for reasoning about or infer states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. Various classification (explicitly and/or implicitly trained) schemes and/or systems (e.g. support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines . . . ) can be employed in connection with performing automatic and/or inferred action in connection with the claimed subject matter.
A classifier is a function that maps an input attribute vector, x=(x1, x2, x3, x4, xn), to a confidence that the input belongs to a class, that is, f(x)=confidence(class). Such classification can employ a probabilistic and/or statistical-based analysis (e.g., factoring into the analysis utilities and costs) to prognose or infer an action that a user desires to be automatically performed. A support vector machine (SVM) is an example of a classifier that can be employed. The SVM operates by finding a hypersurface in the space of possible inputs, which hypersurface attempts to split the triggering criteria from the non-triggering events. Intuitively, this makes the classification correct for testing data that is near, but not identical to training data. Other directed and undirected model classification approaches include, e.g., naive Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, and probabilistic classification models providing different patterns of independence can be employed. Classification as used herein also is inclusive of statistical regression that is utilized to develop models of priority.
The automatic software deployment component 102 can further utilize a presentation component 604 that provides various types of user interfaces to facilitate interaction between a user and any component coupled to the automatic software deployment component 102. As depicted, the presentation component 604 is a separate entity that can be utilized with the automatic software deployment component 102. However, it is to be appreciated that the presentation component 604 and/or similar view components can be incorporated into the automatic software deployment component 102 and/or a stand-alone unit. The presentation component 602 can provide one or more graphical user interfaces (GUIs), command line interfaces, and the like. For example, a GUI can be rendered that provides a user with a region or means to load, import, read, etc., data, and can include a region to present the results of such. These regions can comprise known text and/or graphic regions comprising dialogue boxes, static controls, drop-down-menus, list boxes, pop-up menus, as edit controls, combo boxes, radio buttons, check boxes, push buttons, and graphic boxes. In addition, utilities to facilitate the presentation such as vertical and/or horizontal scroll bars for navigation and toolbar buttons to determine whether a region will be viewable can be employed. For example, the user can interact with one or more of the components coupled and/or incorporated into the automatic software deployment component 102.
The user can also interact with the regions to select and provide information via various devices such as a mouse, a roller ball, a keypad, a keyboard, a pen and/or voice activation, for example. Typically, a mechanism such as a push button or the enter key on the keyboard can be employed subsequent entering the information in order to initiate the search. However, it is to be appreciated that the claimed subject matter is not so limited. For example, merely highlighting a check box can initiate information conveyance. In another example, a command line interface can be employed. For example, the command line interface can prompt (e.g., via a text message on a display and an audio tone) the user for information via providing a text message. The user can then provide suitable information, such as alpha-numeric input corresponding to an option provided in the interface prompt or an answer to a question posed in the prompt. It is to be appreciated that the command line interface can be employed in connection with a GUI and/or API. In addition, the command line interface can be employed in connection with hardware (e.g., video cards) and/or displays (e.g., black and white, and EGA) with limited graphic support, and/or low bandwidth communication channels.
Turning quickly to
Referring back to
The system 700 can further include a proposal wizard 708 that can facilitate evaluation of the distributed network. The proposal wizard 708 can receive inputs that enable a proposal engine 710 to generate a proposal and/or deployment solution based on the collected inventory data stored in the data store 202. The proposal can be, but is not limited to, a document, an email, an electronic document, a graphic, an illustration, a picture, a chart, etc. It is to be appreciate that the proposal wizard 708 can facilitate creating and/or generating any material related to the distributed network current state (e.g. security, software location, network settings, network configurations, devices within the distributed network, etc.), a proposed solution in relation to software needs, a proposal for security related to the environment, trouble-shooting the environment, etc.
The system 700 can also include a deployment planning wizard 712 that can employ a deployment planning engine 714 to assist in generating implementation documents that illustrate the proposed deployment of software in the distributed environment. The implementation document can be any suitable documents related to the possible deployment plan such as, but not limited to, graphs, charts, presentations, pictures, word processing documents, email, web graphics, etc. It is to be appreciated that the deployment planning wizard 712 can create and/or generate any suitable documentation that facilitates illustrating the planned deployment of software, the current improvements to be deployed in the distributed environment, and/or any other possible manipulation ascertained based on the current state of the distributed environment (e.g. updates, upgrades, security improvements, etc.). In one example, the system 700 can utilize an acyclic graph from the inventory data collected (e.g., an inventory graph) to calculate the most efficient path in order to ascertain the opportunities for parallel deployment (e.g. executing something remotely, locally, etc.).
The system 700 can further include a deployment execution wizard 716 that facilitates deploying software in the target distributed environment. The deployment execution wizard 716 can utilize a task sequencer 718 that can efficiently deploy software in the distributed environment to various machines 720 based at least in part upon the deployment planning engine 714 and the deployment planning wizard 712. It is to be appreciated that the data store 202 can be utilized by at least one of the inventory wizard 704, the proposal wizard 708, the deployment planning wizard 712, and the deployment execution wizard 716 as a transactional oriented workflow engine to allow simultaneous execution of programs and/or agents in parallel so software can be deployed efficiently.
At reference numeral 1104, a sequence of deployment for software can be optimally ascertained based on the collected data and topology related to the distributed network. For example, based on the physical topology of the distributed network parallel deployment can be implemented such that particular steps and/or processes are employed in a specific order/sequence. Moreover, such steps and/or processes can be any suitable steps and/or processes related to deploying software within the distributed network (e.g., file installation, user account setup, approvals, upgrades, etc.). In other words, rather than a sequential and/or step-by-step process for software deployment in a distributed network, the software deployment can be in parallel, wherein multiple steps are done simultaneously so as to efficiently deploy such software and significantly decreasing overall deployment time.
At reference numeral 1106, the software can be deployed in a parallel manner based on the topology and distributed network collected data and the optimally ascertained sequence. Thus, the software can be efficiently and automatically deployed in the distributed network utilizing the collected data specific to the target environment (e.g., the distribute environment that data is collected from). Thus, rather than conventionally having a user manually type and/or enter information necessary for software deployment, such information is automatically collected and retrieved to allow automatic deployment of such software with little or no user intervention.
At reference numeral 1204, a report can be created based on the current state of the distributed network. For example, the distributed network can be evaluated based at least in part upon the collected data, wherein such data can shed insight on possible upgrades, manipulations, updates, security breaches, etc. Thus, a proposal can be created and/or generated such that the current state of the distributed network can be identified and logged for evaluation purposes. The proposal/report can be, but is not limited to, a document, an email, an electronic document, a graphic, an illustration, a picture, a chart, etc. It is to be appreciate that the proposal can facilitate creating and/or generating any material related to the distributed network current state (e.g., security, software location, network settings, network configurations, devices within the distributed network, etc.), a proposed solution in relation to software needs, a proposal for security related to the environment, trouble-shooting the environment, etc.
Continuing at reference numeral 1206, the deployment of software can be efficiently evaluated to create a deployment proposal plan. In other words, various data associated with the distributed network can point toward an optimized deployment strategy, wherein such strategy can be documented as a proposal for presentation, illustration, and/or for records. Similar to the report on the current state of the distributed network, the deployment proposal plan can be, but is not limited to, a document, an email, an electronic document, a graphic, an illustration, a picture, a chart, etc. The deployment proposal plan can facilitate illustrating the planned deployment of software, the current improvements to be deployed in the distributed environment, and/or any other possible manipulation ascertained based on the current state of the distributed environment (e.g. updates, upgrades, security improvements, etc.). In one example, an acyclic graph from the inventory data collected (e.g., an inventory graph) can be utilized to calculate the most efficient path in order to ascertain the opportunities for parallel deployment (e.g. executing something remotely, locally, etc.). At reference numeral 1208, the software can be deployed automatically in the distributed network based on the deployment proposal plan.
At reference numeral 1210, verification of at least a portion of the software deployment can be provided. The verification can ensure that a first unit of deployment is successful before the subsequent unit of deployment is initiated. By verifying each unit of deployment, efficient and accurate installation and/or deployment of software within the distributed network can be ensured. In another example, each step can be verified so that the model can halt when a step is incomplete and/or contains an error. Based on a detected error, user intervention can be requested and subsequently return to automatic mode and/or deployment for the software.
In order to provide additional context for implementing various aspects of the claimed subject matter,
Moreover, those skilled in the art will appreciate that the inventive methods may be practiced with other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based and/or programmable consumer electronics, and the like, each of which may operatively communicate with one or more associated devices. The illustrated aspects of the claimed subject matter may also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all, aspects of the subject innovation may be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in local and/or remote memory storage devices.
One possible communication between a client 1310 and a server 1320 can be in the form of a data packet adapted to be transmitted between two or more computer processes. The system 1300 includes a communication framework 1340 that can be employed to facilitate communications between the client(s) 1310 and the server(s) 1320. The client(s) 1310 are operably connected to one or more client data store(s) 1350 that can be employed to store information local to the client(s) 1310. Similarly, the server(s) 1320 are operably connected to one or more server data store(s) 1330 that can be employed to store information local to the servers 1320.
With reference to
The system bus 1418 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), Firewire (IEEE 1394), and Small Computer Systems Interface (SCSI).
The system memory 1416 includes volatile memory 1420 and nonvolatile memory 1422. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1412, such as during start-up, is stored in nonvolatile memory 1422. By way of illustration, and not limitation, nonvolatile memory 1422 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory 1420 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM).
Computer 1412 also includes removable/non-removable, volatile/non-volatile computer storage media.
It is to be appreciated that
A user enters commands or information into the computer 1412 through input device(s) 1436. Input devices 1436 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 1414 through the system bus 1418 via interface port(s) 1438. Interface port(s) 1438 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 1440 use some of the same type of ports as input device(s) 1436. Thus, for example, a USB port may be used to provide input to computer 1412, and to output information from computer 1412 to an output device 1440. Output adapter 1442 is provided to illustrate that there are some output devices 1440 like monitors, speakers, and printers, among other output devices 1440, which require special adapters. The output adapters 1442 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 1440 and the system bus 1418. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 1444.
Computer 1412 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 1444. The remote computer(s) 1444 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 1412. For purposes of brevity, only a memory storage device 1446 is illustrated with remote computer(s) 1444. Remote computer(s) 1444 is logically connected to computer 1412 through a network interface 1448 and then physically connected via communication connection 1450. Network interface 1448 encompasses wire and/or wireless communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).
Communication connection(s) 1450 refers to the hardware/software employed to connect the network interface 1448 to the bus 1418. While communication connection 1450 is shown for illustrative clarity inside computer 1412, it can also be external to computer 1412. The hardware/software necessary for connection to the network interface 1448 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
What has been described above includes examples of the subject innovation. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the subject innovation are possible. Accordingly, the claimed subject matter is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.
In particular and in regard to the various functions performed by the above described components, devices, circuits, systems and the like, the terms (including a reference to a “means”) used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., a functional equivalent), even though not structurally equivalent to the disclosed structure, which performs the function in the herein illustrated exemplary aspects of the claimed subject matter. In this regard, it will also be recognized that the innovation includes a system as well as a computer-readable medium having computer-executable instructions for performing the acts and/or events of the various methods of the claimed subject matter.
In addition, while a particular feature of the subject innovation may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms “includes,” and “including” and variants thereof are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term “comprising.”
