As part of my job function at Novell I have been doing some research on Desktop Virtualization, which by definition is a broad topic that covers many technologies and solutions. One area of interest is Application Virtualization so I decided, through a series of blog posts, to explore and explain this area of virtualization.
Application virtualization is a relatively new concept on the desktop but in the last few years mature products for the Windows platform have sprung up and are now evaluated and deployed in the Enterprise. While researching this topic I also discovered a few companies attempting to provide this technology for the Linux platform as well.
Most application virtualization products consist of four distinct technologies: Profiler, Framework, Stream Engine and Management. In my own words, I will attempt to introduce these components and give the reader an understanding what this all means and then you as the reader may or may not jump on the bandwagon and consider this a hot technology.
An Application Profiler is a utility program that monitors a specific application or in some cases a group of applications running under normal conditions in a clean pristine environment. It's the profiler's job to capture all shared resources the application might use or depend on. From this captured log the profiler usually builds some type of application bundle. Depending on the implementation, the bundle usually contains the application itself, the dependent shared libraries and some sort of description file which details what configuration was written or updated by the application. The profiler must also capture any bits the application creates in the file system outside of configuration that aren't considered bits generated by the user driving the application. The description file could also contain required environment variables and command line parameters required for the application to startup correctly. Some products allow an application bundle to contain more than one application and normally call these application clusters.
The Application Framework is responsible for importing the application bundle, launching the application and then of course containing or compartmentalizing the application in it's own private environment. For true virtualization an instance of all shared resources must exist inside the compartment and cannot be accessible by the native running native applications or applications running in a different compartment. Depending on the implementation and flexibility of the Framework, the author of the application bundle determines what pieces of the shared resources are actually pulled into the bundle itself. The author could choose to pull all shared resources into a bundle or possibly only pull the application itself and the configuration registry. Most frameworks then overlay the bundle resources on top of the native resources to prevent the full “view” back to the application. It's the frameworks job to determine when to use bundle resources over native resources. Bundles and Application Frameworks make it easy to run multiple of versions of an application on a single desktop without collisions. Another major feature an Application Virtualization Framework provides is bundle removal, usually with one click of the mouse the application, resources and any bits the application may have produced are completely removed from the system. In native environments, IT desktop admins are depending on the application's install package to properly clean up and remove itself, which is not always the case. The framework must also integrate with the desktop application browser so the user can view and launch the virtualized bundles using the same tools and mechanisms they normally would use.
Application Streaming is a coordinated dance between the desktop virtualization framework and a bundle streaming component on the server. The purpose for streaming is to move an application bundle or parts of a bundle from an IT managed server down to a users desktop where it then is imported into the desktop virtualization framework. Depending on policy or how the download was initiated the application could immediately launch or start later at a scheduled time. Most software bundles are kept persistent on the user's desktop after the initial complete download. Application licensing and or user validation is usually performed against the streaming server as well. As an example, when a user first launches an application bundle that had previously been downloaded, the framework would first call the streaming server to verify the current user is still authorized to run the application. Most implementations also have policy to enable mobile workers to run the application in an offline mode. In this mode, policy dictates how long an application is allowed to run without contact with the streaming component on the server. For example, the streaming server administrator may set policy to allow offline applications to continue to run for 10 days without contact. The desktop framework being the policy enforcer would disable or possibly remove the application after 10 days of isolation.
The last technology piece in the solution is a server side management framework for application bundles. Once an application bundle is authored on an “authoring” desktop the administrator needs a mechanism to upload the new bundle to the bundle cloud. Once in the cloud, the administrator can then setup policy on the bundle such as who is allowed to see and stream the bundle down to the desktop. Some solutions offer sparse capabilities for application bundle management while others are extremely comprehensive. Also, most solutions allow integration with existing identity systems for bundle identity itself but also for user/group to bundle relationships.
In the next post of the series, I will drill down and explain how desktop application virtualization has been implemented on the Windows platform. Later I want to explore the possibilities for application virtualization on the Linux desktop.
