Satisfying application dependencies

The present invention relates to satisfying application dependence.

A computer application program (application) typically has a set of dependencies required for the successful deployment and execution of an application. These dependencies can include access to resources such as databases, applications, hardware components, network connections, and the like. Many of these dependencies exist because they are connected to the corporate network while the device is operating locally within the corporate network. However, after the device is no longer connected to the corporate network, for example when the device leaves the corporate premises, the device can no longer connect to the corporate network. As a result, many of the application dependencies that existed because the device is connected to the corporate network no longer exist. Therefore, the application cannot be deployed or run on the device until the dependency is restored.

One mechanism for restoring application dependency requires that a connection be established with the corporate network. For example, a corporate user working from home may need to connect to a corporate network via a virtual private network (VPN) to reestablish dependencies. However, using connections in this way can be cumbersome or expose the corporate network to security threats.

The disclosures made herein are presented with respect to these and other considerations.

<p num="0005"><patcit num="1"><text>U.S. Pat. No. 7225264</text></patcit><patcit num="2"><text>U.S. Pat. No. 7,200632</text></patcit><patcit num="3"><text>U.S. Pat. No. 7,451,451</text></patcit><patcit num="4"><text>U.S. Pat. No. 7977372</text></patcit></p>

Techniques for satisfying the dependencies of virtualized applications are described herein. Application dependencies can be identified and restored at application run time through implementations of the concepts and techniques presented herein. As a result, the client device can successfully deploy and run the application without having to establish a back-end connection between the device and the corporate network. As used herein, the term "dependency" refers to any resource that an application needs to run. Dependencies can include, but are not limited to, configuration settings, hardware components, network connections, access privileges, or any other type of resource.

According to one aspect provided herein, application virtualization allows a virtualized application to run by configuring the client device to have all the dependencies of the virtualized application. The environment is provided. It should be understood that the scope of this disclosure is not limited to use within an application virtualization environment. Instead, the embodiments disclosed herein can be used to satisfy the dependencies of any type of application running in a virtualized or non-virtualized environment.

According to another aspect, when a request is received to deploy a virtualized application, the application virtualization client component has essential dependencies for deploying the virtualized application. Determine if you want to. If the application virtualization client component determines that there are no dependencies, the application virtualization client component configures the client device so that there are dependencies. If the application virtualization client component determines that there is a dependency, the application virtualization client component deploys the virtualized application for execution.

According to another aspect, the application virtualization client component also provides a security boundary between virtualized and non-virtualized applications so that non-virtualized applications cannot access certain resources. Is configured to provide. For example, in one embodiment, an application virtualization client component is an application programming interface (API) made by a virtualized application to access a resource, such as a request to access a resource available to a client device. Intercept the call. The application virtualization client component then modifies the requested resource namespace so that the resource is accessible in the new location. In some embodiments, the application virtualization client component can also modify the access control list (ACL) associated with the resource and pass the API call to the resource stored in the new location. Requests from non-virtualized applications to access a resource cannot access the resource in a new location.

According to another aspect, application dependency is identified prior to run time by performing static analysis on the application. In one embodiment, the virtualized application is installed on a surveillance station that provides an environment in which all the dependencies of the virtualized application exist. The monitoring station's dependency analysis engine monitors for changes made to the monitoring station during the installation and execution of virtualized applications to identify dependencies. When monitoring a virtualized application, the dependency analysis engine stores data that identifies the dependency in the dependency analysis database. The dependency analysis database can be used when the application is run to ensure that all required dependencies are present.

This summary does not identify the material or essential features of the claims and is not intended to be used to limit the scope of the claims. Moreover, the claims are not limited to examples that resolve any or all of the shortcomings pointed out in any part of this disclosure.

<figref num="1">FIG. 6 is a software and network architecture diagram illustrating an exemplary operating environment of one of the embodiments disclosed herein.</figref><figref num="2">It is a schematic showing one process for identifying the dependency of a virtualized application according to one embodiment presented herein.</figref><figref num="3">It is a flow diagram which shows the aspect of one exemplary process disclosed herein for identifying the dependency of a virtualized application in the operation of a learning mode according to one embodiment presented herein. ..</figref><figref num="4">FIG. 5 is a flow diagram illustrating an aspect of one exemplary process disclosed herein to satisfy the dependencies of a virtualized application according to one embodiment presented herein.</figref><figref num="5">It is a schematic diagram illustrating one process according to one embodiment presented herein to provide a security boundary and prevent an external non-virtualized application from accessing a resource.</figref><figref num="6">A flow illustrating an aspect of one exemplary process disclosed herein to provide a one-way security boundary to prevent an external application from interacting with a resource, according to one embodiment presented herein. It is a figure.</figref><figref num="7">FIG. 6 is a computer architecture diagram illustrating exemplary computer hardware and software architecture of a computing system that can implement the various embodiments presented herein.</figref>

The following detailed description covers techniques for satisfying application dependencies. As briefly discussed above, client devices configured in the manner disclosed herein can identify application dependencies and make those dependencies available at application runtime. In this scheme, the client device can be configured for application execution without the need for manual action to satisfy dependencies, such as connecting to a VPN.

The objects described herein are presented in the general context of program modules that run in conjunction with the execution of operating systems and application programs on computer systems, while other examples are of other types of programs. Those skilled in the art will understand that it can be performed in combination with modules. In general, a program module includes routines, programs, components, data structures, and other types of structures that perform a particular task or implement a particular abstract data type. In addition, the objects described herein are other computer systems, including handheld devices, multiprocessor systems, microprocessor-based or programmable home appliances, minicomputers, mainframe computers, and the like. Those skilled in the art will understand that it can be implemented in a configuration.

In the following detailed description, reference is made to the accompanying drawings which form part of this specification and show specific embodiments or examples as examples. Here, with reference to the drawings, similar numbers represent similar elements through several figures, and aspects of computational systems and methodologies for satisfying application dependencies are described.

FIG. 1 is a software and network architecture diagram showing an exemplary operating environment 100 of one of the embodiments disclosed herein. The exemplary operating environment 100 shown in FIG. 1 includes a client device 102 configured to communicate with the server 104 over the network 106. Client device 102 is a computing device configured to run operating system 108A and application virtualization client component 110. The client device 102 is a standard desktop or laptop computer, tablet computer, smartphone, or any other type capable of performing the actions presented herein to meet the dependencies of a virtualized application. It may be a computing device of. The client device 102 may also be a server computer configured to provide the functionality disclosed herein.

Server 104 is a computing system configured to run operating system 108B and application virtualization server component 120. The server 104 may be an actual server computer configured to run the application virtualization server component 110, or to perform the functionality described herein as being run by the server 104. It should be understood that it may include another type of computer system configured.

The network 106 shown in FIG. 1 may include a wide area network or a local area network. For example, the network 106 may be a corporate local area network, a wide area network such as the Internet, or a combination of a plurality of wide area networks and local area networks. Although a single network 106 is shown in Figure 1, it should be understood that many other networks can be used. Although a single client device 102 and server 104 are shown in FIG. 1, it should also be appreciated that a number of such devices can be used by the embodiments disclosed herein.

As briefly discussed above, the client device 102 is configured to execute the application virtualization client component 110. The application virtualization client component 110 is a software component configured to provide an application virtualization environment. In this regard, the application virtualization client component 110 is configured to deploy and run the virtualized application 112.

Application virtualization client component 110 provides functionality for encapsulating the execution of virtualized application 112 from operating system 108A. The application virtualization client component 110 can also provide functionality for encapsulating the execution of the virtualized application 112 from other application programs and system resources of the client device 102. For example, the application virtualization client component 110 can virtualize the resources of operating system 108A or client device 102. When the virtualized application 112 attempts to access a physical resource, the application virtualization client component 110 presents the virtualized resource to the application 112. In this way, the virtualized application 112 can run in a way that does not affect the actual resources exposed by operating system 108A or client device 102.

According to another aspect, the application virtualization client component 110 also provides functionality for loading a portion of the virtualized application 112 on demand. Specifically, the application virtualization client component 110 operates in conjunction with the application virtualization server component 120 to flow the required portion of the virtualized application 112 from the server 104 to the client device 102. Can be done. In this scheme, the virtualized application 112 is accessible on the client device 102 upon request. Further, since only the required portion of the virtualized application 112 can flow from the server 104 to the client device 102, access to the virtualized application 112 is the entire application 112 from the server 104 to the client device 102. It can be provided without shedding.

Further details on the functionality provided by the application virtualization client component 110 for encapsulating the execution of the virtualized application 112 and for streaming the virtualized application 112 from the server 104 to the client device 102, respectively. US Pat. No. 7,225,264, "Systems and Methods for Delivering Content over a Computer Network," filed May 29, 2007, which is incorporated herein by reference in its entirety, April 3, 2007. US Pat. No. 7,200632 filed "Method and System for Serving Software Applications to Client Computers" and US Pat. No. 7,451,451 filed November 11, 2008 "Operating System Abstraction and Protection" It can be found in "Layer" and in US Pat. No. 7977372, "Serving Software Applications from Servers for Client Computers," filed September 14, 2010.

As described in more detail herein, the application virtualization client component 110 also ensures that one or more dependencies 114 of the virtualized application 112 are satisfied at run time of the application 112. Can be configured. As used herein, the term "dependency" refers to any resource that application 112 needs to run. Dependencies are configuration settings, hardware components, network connectivity, access privileges, the presence of specific files in specific locations, application resources such as antivirus software installations, and hardware components such as monitors or other devices. , Required memory, processing functions, etc., but are not limited to these.

As discussed in more detail below, dependency 114 can be identified during application 112 installation, before application 112 runs, or at application 112 run time. For example, when a request to run a virtualized application 112 is received, the application virtualization client component 110 has an essential dependency 114 to deploy and / or run the virtualized application 112. Determines if is present. If the application virtualization client component 110 determines that the dependency 114 does not exist, the application virtualization client component 110 configures the client device 102 so that all of the dependencies 114 exist. The virtualized application 112 is deployable after all of the dependencies 114 are present or satisfied. As used herein, the term "deploy" means to make application 112 available for execution. Further details regarding the configuration of the client device 102 such that all of the dependencies 114 are present are provided below with respect to FIGS. 2-4.

It should be understood that the client device 102 may also include a non-virtualized external application 118 that may run on operating system 108A. As described in more detail below, application virtualization client component 110 is a feature in one embodiment that ensures that external application 118 does not have access to the resources used by virtualized application 112. Provide sex. For example, the application virtualization client component 110 can forward a request to access a resource to a location where the resource does not exist. In this way, the operating system can respond to requests indicating that the requested resource does not exist or cannot be found. Further details regarding this process are provided below with respect to FIGS. 5-6.

As mentioned above, server 104 may include virtualized application 112, application virtualization server component 110, and operating system 108B. In addition, the server 104 may include a dependency analysis engine 122 and a dependency analysis database 124 for storing dependency data 126 that identifies the dependency 114. It should be understood that the dependency analysis database 124 containing the dependency data 126 can also be stored and / or made accessible to the application virtualization client component 110 of the client device 102. According to an embodiment, the server 104 may act as a surveillance station configured to install and run the virtualized application 112 and to identify the dependency 114 of the virtualized application 112. it can. According to various embodiments, the dependency analysis engine 122 identifies the dependency 114 of the virtualized application 112 and stores the dependency data 126 that identifies the subordinate attribute 114 in the dependency analysis database 124. Can be done. User interface 130 may also be provided for viewing and editing the contents of database 124. Further details regarding the various processes provided herein for identifying dependency 114 are provided below with respect to FIGS. 2 and 3.

It should be understood that the embodiments described herein are for illustration purposes only and do not limit the scope of the present application to the embodiments described herein. The techniques described herein can be applied with various types of applications, and the embodiments disclosed herein are not limited to satisfying the dependencies of virtualized application 112. Those skilled in the art will understand. The concepts described herein may also apply to any type of application, including but not limited to virtualized and non-virtualized applications that run in virtualized and non-virtualized environments. I want to be understood.

FIG. 2 is one for identifying the dependencies of the virtualized application 112 while the virtualized application 112 is running in one environment, according to one embodiment presented herein. It is the schematic which shows the process. Specifically, FIG. 2 shows a mode of learning mode of motion used to identify dependency 114. In the learning mode operation, the API call interceptor 202 intercepts the API call made by the application 112 to access the resource. As discussed below, API calls can be made during application 112 runtime or when application 112 is installed.

When the virtualized application 112 is installed on a device such as client device 102, the application 112 installer can make changes to device 102. For example, various files related to the virtualized application 112 can be stored, or registry files can be created or modified. The dependency analysis engine 122 monitors the installation of application 112 to detect any configuration changes that result from the installation of virtualized application 112. The dependency analysis engine 122 also configures the computer running the dependency analysis engine 122 before the virtualized application 112 is installed with the configuration after the virtualized application 112 is installed. You can also compare. The dependency analysis engine 122 can then use the detected changes to identify the dependency 114. Dependency data 126 that identifies the dependency 114 is then stored in the dependency analysis database 124.

As part of the learning mode behavior, the dependency analysis engine 122 can also monitor the virtualized application 112 at runtime. When the virtualized application 112 is running, the virtualized application 112 can make API calls to access resources. The API call interceptor 202 hooks the API call made by the virtualized application 112 and passes the call to the dependency analysis engine 122, where the API call relates to the additional dependency 114 of the virtualized application 112. Inspected to collect information. API calls can include requests to access specific resources such as files and databases. In addition, API calls may include requests to access a particular application.

The dependency analysis engine 122 inspects the intercepted API call to identify the run-time dependency 114 of the virtualized application 112. The dependency analysis engine 122 can store data that identifies the run-time dependency 114 in the dependency analysis database 124. In addition, the data may be stored in database 124, which indicates whether the identified dependency 114 is provided by operating system 108. In an alternative embodiment, data identifying the run-time dependency 114 may flow from the server 104 to the client device 102. In such an embodiment, the dependency-identifying data can be packaged in an application package that can be configured to flow to the client device 102. As described in more detail below, the data generated during the operation of learning mode is used when application 112 is running to ensure that all of the dependencies 114 are available to application 112. For example, dependency data 126 stored in database 124 can be used to determine whether application execution is dependent on any resource not provided by the operating system. If so, the resource can be made available to the application.

It should be understood that not all resources may be made available to the application. In such situations, the application may not be able to deploy on the device until those resources are made available and all of the application's dependencies are properly met. For example, a company may have documents that can only be accessed from within the company's building. When a user outside the corporate building runs an application that interacts with those documents, the application virtualization client component 110 can prevent the application from accessing the document. In this case, the dependency may be the presence of a corporate IP address indicating that the user is in a corporate building. If the user is not in the corporate building, the dependency corresponding to the existence of the corporate IP address is not satisfied and the virtualized application 112 cannot be deployed.

FIG. 3 is a flow diagram illustrating an aspect of one exemplary process disclosed herein for identifying the dependency 114 of the application 112 virtualized in the learning mode described above. The logic behaviors described herein with respect to FIGS. 3, 4, and 6 are (1) as a sequence of program modules running on a computer-implemented behavior or computational system, and / or (2) computation. It should be understood that it is implemented as an interconnected logic circuit or circuit module in the system. Implementation is a matter of choice depending on the performance of the computing system and other requirements. Therefore, the logical actions described herein are variously referred to as actions, structural devices, actions, or modules. These actions, structural devices, actions and modules can be implemented in software, in firmware, in purpose-built digital logic, and in combinations thereof. It is also appreciated that more or less actions may be performed than those illustrated and described herein. These operations can also be performed in a different order than those described herein.

FIG. 3 shows a routine 300 that describes the actions shown in FIG. 2 and performed in the learning mode of the above actions. Routine 300 starts with operation 302, where the virtualized application 112 is installed on a monitoring system such as server 104. The server 104 includes a dependency analysis engine 122 that provides the aforementioned functionality for identifying the dependency 114 of the virtualized application 112. The server 104 may also contain all the dependencies 114 that are essential for the proper installation and execution of the virtualized application 112. In this scheme, the virtualized application 112 can run on the server 104 in learning mode. It should be understood that another computer other than server 104 can be used as a monitoring station to perform the learning process described herein.

According to one embodiment, when the server 104 is operating in learning mode, the dependency analysis engine 122 identifies the dependency 114 of the virtualized application 112 and the dependency data 126 that identifies the dependency 114. Is configured to monitor changes made to server 104 that stores in the dependency analysis database 124. Dependencies 114 may include dependencies identified by analyzing the installation and configuration of application 112, as well as dependencies identified by intercepting API calls made by application 112 virtualized at run time. ..

From operation 302, routine 300 proceeds to operation 304, where the dependency analysis engine 122 monitors for changes made during the installation of the virtualized application 112. The dependency analysis engine 122 monitors changes by comparing the system configuration settings prior to the installation of the virtualized application 112 with the system configuration settings after the virtualized application 112 is installed. Can be done. In addition, the dependency analysis engine 122 monitors various resources of the system, such as changes made to the registry or the creation of additional files and folders related to the installation of the virtualized application 112, to determine the dependency 114. Can be identified.

From operation 304, routine 300 proceeds to operation 306, where the virtualized application 112 is executed. During execution, the dependency analysis engine 122 virtualizes API calls made by the virtualized application 112 to access resources, as well as any configuration changes made as a result of the execution of the virtualized application 112. Continuously monitor the virtualized application 112.

From action 306, routine 300 proceeds to action 308, where the API call interceptor 202 intercepts the API call made by the virtualized application 112. The API call interceptor 202 can then provide these API calls to the dependency analysis engine 122. From operation 308, routine 300 proceeds to operation 310, where the dependency analysis engine 122 examines the parameters of the intercepted API call to identify the dependency 114 of the virtualized application 112. As mentioned above, API calls can include requests to access a particular resource, such as a file, application, or hardware component such as a speaker or display. As such, the dependency analysis engine 122 has the ability to determine the run-time dependency of the virtualized application 112 by inspecting the format and content of the intercepted API calls.

From operation 310, routine 300 proceeds to operation 312, where the dependency analysis engine 122 was collected during the installation and execution of the virtualized application 112, which identifies the dependency 114 in the dependency analysis database 124. Stores dependency data 126. According to one embodiment, the dependency analysis database 124 may be stored on server 104, or anywhere else accessible by client device 102 or server 104 via network 106.

From operation 312, routine 300 proceeds to operation 314, where a decision is made as to whether each of the dependency 114s of the virtualized application 112 is added or configured during the installation or deployment of the virtualized application 112. Will be done. This can be achieved, for example, by examining the operating system-provided registry. Alternatively, this is achieved by examining the mapping table that maps API calls to dependencies. The mapping table may contain information indicating whether each dependency is provided by the operating system.

From action 314, if dependencies are added or configured during application installation or deployment, routine 300 proceeds to action 316. In operation 316, data is added or configured during the installation or deployment of the virtualized application 112 to allow the client at run time to successfully deploy the virtualized application 112 on the client device 102. It is stored in the dependency analysis database 124, which indicates that it will need to be present on device 102. If action 314 determines that dependency 114 is not added or configured during installation or deployment of the virtualized application 112, routine 300 proceeds to action 318, where routine 300 exits. Similarly, from operation 316, routine 300 also proceeds to operation 318, where routine 300 ends.

After the dependency 114 of the virtualized application 112 is identified and the dependency data 126 that identifies the dependency 114 is stored in the dependency analysis database 124, the virtualized application 112 is deployed on the client device 102. can do. However, prior to deploying the virtualized application 112 on the client device 102, the dependencies 114 required to deploy the virtualized application 112 must be accessible by the client device 102. There can be. In one embodiment, the dependency data 126 that identifies the dependency 114 is stored on the client device 102 and used by the application virtualization client component 110 so that the dependency 114 of the virtualized application 112 is the client device 102. Ensure that it exists at run time of deployment of virtualized application 112 in. Further details regarding this process are provided below with respect to Figure 4.

FIG. 4 illustrates an aspect of one exemplary process disclosed herein for satisfying the dependency of virtualized application 112 on client device 102 according to one embodiment presented herein. , It is a flow chart. Specifically, FIG. 4 shows a routine 400 that describes the actions performed when application 112 is executed. Specifically, routine 400 begins at action 402, where application virtualization client component 110 receives a request to deploy the virtualized application 112 on client device 102. According to one embodiment, the user of the client device 102 can submit a request to deploy the virtualized application 112 on the client device 102.

From action 402, routine 400 proceeds to action 404, where the application virtualization client component 110 determines the dependency 114 of the virtualized application 112 by querying the dependency analysis database 124. The application virtualization client component 110 can also query the dependency analysis database 124 to determine if the identified dependencies are provided by the operating system 108. If so, the dependencies do not need to be restored at run time by the application virtualization client component 110.

From action 404, routine 400 proceeds to action 406, where application virtualization client component 110 determines if all of the dependencies 114 are present. According to some embodiments, the application virtualization client component 110 performs it by comparing the dependency 114 determined by the secondary attribute analysis engine 122 during learning mode with the dependency present on the client device 102. It can be performed. If the application virtualization client component 110 determines that all of the dependencies 114 are present, routine 400 proceeds to operation 414, where the application virtualization client component 110 sends the virtualized application 112 to the client device 102. Expand on.

However, in operation 406, if the application virtualization client component 110 determines that all of the dependencies 114 are not present on the client device 102, routine 400 proceeds from operation 406 to operation 408, where application virtualization. Client component 110 identifies the missing dependency. Missing dependencies can be resources that do not exist or are not properly configured. For example, if one of the dependencies 114 involves activating a firewall on client device 102, application virtualization client component 110 inspects client device 102 to see if the firewall is activated. be able to. If the firewall is not activated, then the application virtualization client component 110 identifies the firewall as a missing dependency.

From operation 408, routine 400 proceeds to operation 410, where application virtualization client component 110 configures client device 102 so that the missing dependencies are satisfied. The application virtualization client component 110 configures the client device 102 in such a way that the configuration settings of the client device 102 match the configuration settings of the server 104 when the virtualized application 112 is installed and run on the server 104. You can do that by doing. Using the example above, the application virtualization client component 110 can activate the firewall automatically by changing the firewall settings on the client device 102. In some embodiments, the application virtualization client component 110 can also make resources available. In this way, the application virtualization client component 110 can configure the client device 102 to meet the dependencies 114 that are essential for deploying and / or running the application.

From operation 410, routine 400 proceeds to operation 412, where application virtualization client component 110 determines if there are any more missing dependencies 114. If the application virtualization client component 110 determines that there are still missing dependencies 114, routine 400 returns to operation 406, where routine 400 identifies another missing dependency. However, if application virtualization client component 110 determines that there are no more missing dependencies 114, routine 400 proceeds to operation 414, where application virtualization client component 110 sends the virtualized application 112. expand. From action 414, routine 400 proceeds to action 416, where routine 400 ends. It should be understood that the application virtualization client component 110 may not be able to meet all the dependencies required to deploy the virtualized application 112. For example, in the example above, the application virtualization client component 110 may not be able to satisfy dependencies such as the presence of a corporate IP address provided only to devices operating within the corporate building.

FIG. 5 is a schematic diagram showing the process of providing security boundaries to prevent external applications from accessing the resources available to application 112. According to some embodiments, a non-enterprise application installed on a client device 102, such as an external application 118, may attempt to gain access to the resources used by the virtualized application 112. .. This can pose a security threat and therefore efforts may be made to prevent external application 118 from interacting with resources. In one embodiment, the client device 102 provides functionality for forwarding API calls made by the external application to prevent the external application 118 from accessing the resource. In some embodiments, this transfer can occur by modifying the name of the resource (sometimes referred to herein as "namespace mangling"). Figure 5 shows one process provided herein to perform this functionality.

When the virtualized application 112 makes an API call to access or modify an external resource, the routing layer 502 intercepts the API call and performs two functions. First, the routing layer 502 causes the original resource 504 to be renamed, thereby creating the renamed resource 506. As a result, external application 118 running outside application virtualization client component 110 cannot see inside the expected location of the resource. In this way, bizarre applications are prevented from trying to gain access to resources. However, the determined external application 118 can still open and access the original resource 504. To prevent any determined external application from accessing the resource, the application virtualization client component 110 also prevents the external application 118 from opening or accessing the resource 504 from the original resource 504. You can also modify access control lists (ACLs) to customized ACLs. FIG. 6 illustrates an additional aspect of this process.

It should be understood that the application virtualization client component 110 can have multiple copies of the resource and can transfer different processes to see different versions of the resource. For example, client device 102 can have two copies of the registry value named "foo", one copy set to 0 and the other set to 1. When one process accesses the registry value, client device 102 transparently transfers the process to a copy of the resource set to 0. When another process accesses what it considers to be the same registry value, client device 102 transparently transfers this process to a copy of the resource set to 1. Both processes are trying to access the resource, but client device 102 is transferring them to differently named instances of the resource without being noticed by them. In this way, these two processes are receiving different input values, so they can perform two separate actions. As a result, the client device 102 can provide the correct input value to the authorized application, while it can provide the incorrect input value to the unauthorized application, providing security to the client device 102. it can.

In another example, when two processes try to access the file, client device 102 can transfer one of them to a valid copy of the file and the other one has the file. You can tell it didn't exist, or you can transfer it to a location where the file doesn't exist so that the operating system can respond. As a result, unauthorized processes cannot be provided access to the file.

FIG. 6 is a flow diagram illustrating an aspect of one exemplary process disclosed herein to provide a security perimeter. Specifically, FIG. 6 shows a routine 600 illustrating an operation performed in one embodiment for providing security boundaries in the manner described above with reference to FIG.

Routine 600 begins at action 602, where routing layer 502 intercepts API calls made by virtualized application 112 to access the resource. As mentioned above, the routing layer 502 can only intercept API calls made by the virtualized application 112. From action 602, routine 600 proceeds to action 604, where routing layer 502 selects a copy of the resource to which the API call made by the virtualized application 112 will be forwarded. A copy of the resource can be previously saved by the operating system. From operation 604, routine 600 proceeds to operation 606, where the operating system 108A further rewrites the ACL associated with the resource so that the resource is not accessible to external applications running outside the application virtualization client component 110. Configure. From action 606, routine 600 proceeds to action 608, where the intercepted API call is routed to the renamed resource 506.

From operation 608, routine 600 proceeds to operation 610, where operating system 108A receives an API call requesting access to the resource from external application 118. According to the embodiment, the external application 118 communicates directly with the operating system 108A without going through the application virtualization client component 110, so that the operating system 108A receives the API call from the external application 118. However, it should be understood that external applications can send API calls through the application virtualization client component 110. In such an embodiment, the application virtualization client component 110 does not perform any of the transfers, but instead passes the original API call to the operating system 108A for processing by the operating system 108A.

From operation 610, routine 600 proceeds to operation 612, where operating system 108A routes the API call from the external application 118 to the original resource 504. In this way, API calls made by non-enterprise applications such as external application 118 cannot access resource 506. From operation 612, routine 600 proceeds to operation 614, where routine 600 ends.

FIG. 7 is a computer architecture diagram illustrating exemplary computer hardware and software architecture for a computing system capable of implementing the various embodiments presented herein. The computer architecture shown in FIG. 7 illustrates a conventional desktop, laptop, or server computer and can be used to perform the various software components described herein.

The computer architecture shown in Figure 7 consists of a central processing unit 702 (CPU), system memory 708 including random access memory 714 (RAM) and read-only memory (ROM) 716, and memory concatenated to CPU 702. Includes system bus 704 and so on. A basic I / O system (BIOS) that contains basic routines that help transfer information between elements in the computer 700, such as during boot, is stored in ROM716. The computer 700 further includes a mass storage device 710 for storing the operating system 718, application programs, and other program modules, which are described in more detail below.

The mass storage device 710 is connected to the CPU 702 via a mass storage controller (not shown) connected to the bus 704. Mass storage device 710 and associated computer readable storage media provide a non-volatile storage device for computer 700. Although the description of a computer-readable medium included herein refers to a mass storage device such as a hard disk or CD-ROM drive, the computer-readable storage medium is any usable computer storage that can be accessed by the computer 700. Those skilled in the art will understand that it may be a medium.

As an example, and without limitation, computer-readable storage media are volatile and non-volatile, implemented in any way or technique for the storage of information such as computer-readable instructions, data structures, program modules or other data. It may include volatile, removable and non-removable media. For example, computer readable storage media include RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disc (DVD), HD-DVD, BLU-RAY®. ), Or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage device devices, or can be used to store desired information and can be accessed by computer 700. Including, but not limited to, any other non-temporary medium that can be.

It should be understood that the computer-readable media disclosed herein also include communication media. The communication medium usually carries other data in a modulated data signal such as a computer-readable instruction, a data structure, a program module, or a carrier wave or other transfer mechanism, and includes any information distribution medium. The term "modulated data signal" means a signal that has one or more of a set of characteristics or has been modified, such as by encoding information in the signal. By way of example, and without limitation, communication media includes wired media such as wired networks or direct wired connections and wireless media such as sound waves, RF, infrared and other wireless media. Any combination of the above may also be included within the scope of computer readable media. Computer-readable storage media do not include communication media.

According to various embodiments, the computer 700 can operate in a networked environment that uses a logical connection to a remote computer over a network, such as network 720. The computer 700 can be connected to the network 720 via the network interface unit 706 connected to the bus 704. It should be understood that the network interface unit 706 can also be used to connect to other types of networks and remote computer systems. The computer 700 may also include an input / output controller 712 for receiving and processing inputs from multiple other devices, including a keyboard, mouse, or electronic stylus (not shown in FIG. 7). Similarly, an input / output controller can provide output to a display screen, printer, or other type of output device (also not shown in Figure 7).

As briefly mentioned above, multiple program modules and data files are a large storage device 710 for computer 700, including an operating system 718 suitable for controlling the behavior of networked desktops, laptops, or server computers. And can be stored in RAM714. The mass storage devices 710 and RAM 714 can also store one or more program modules. Specifically, the mass storage device 710 and RAM 714 can store the virtualized application 112, the application virtualization client component 110, and / or the other software components described above. Mass storage devices 710 and RAM 714 can also store other program modules and data, such as dependency 114.

In general, when a software application or module is loaded and executed on the CPU 702, it transforms the CPU 702 and the entire computer 700 from a general purpose computing system into a purpose-built computing system customized to perform the functionality presented herein. can do. The CPU 702 can be constructed from any number of transistors or other discrete circuit elements that can assume any number of states individually or collectively. More specifically, the CPU 702 can operate as one or more finite state machines in response to executable instructions contained within the software or module. These computer-executable instructions transform the CPU702 by specifying how the CPU702 transitions between states, thereby physically transforming the transistors or other discrete hardware elements that make up the CPU702. can do.

Encoding software or modules on mass storage devices can also transform the physical structure of mass storage devices or associated computer-readable storage media. Specific modifications of the physical structure may depend on various factors in the different embodiments herein. Examples of such factors may include techniques used to implement computer-readable storage media, regardless of whether the computer-readable storage medium is characterized as a primary or secondary storage device, etc. , Not limited to this. For example, if a computer-readable storage medium is implemented as a semiconductor-based memory, the software or module can transform the physical state of the semiconductor memory as the software is encoded in the semiconductor memory. For example, software can transform the state of transistors, capacitors, or other discrete circuit elements that make up a semiconductor memory.

As another example, computer readable storage media can be implemented using magnetic or optical technology. In such an implementation, the software or module can transform the physical state of the magnetic or optical medium as the software is encoded there. These modifications may include altering the magnetic properties of a particular location within a given magnetic medium. These modifications may also include altering the physical characteristics or properties of a particular location within a given optical medium in order to alter the optical properties of those locations. Other modifications of the physical medium are possible without departing from the scope and intent of this specification, with the above examples provided solely to facilitate this paper.

Based on the above, it should be understood that techniques for ensuring that application dependencies are met at run time are presented herein. Although the objects presented herein are described in computer structural features, methodological behavior, and languages specific to computer-readable media, the invention as defined in the appended claims is described herein. It will be appreciated that it is not necessarily limited to the particular characteristics, behaviors, or media described in the book. Instead, these particular features, behaviors and media are disclosed as exemplary forms that implement the claims.

The above object is provided as an example only and should not be construed as a limitation. Various modifications and modifications do not follow the illustrated and described exemplary embodiments and applications, and without departing from the true spirit and scope of the invention as set forth in the claims below. It can be done to the objects described herein.