A term that I've been hearing more frequently in the past few months is "desktop virtualization." What does that mean anyway? It seems to me that this could be the use of any one of several different virtualization technologies in several categories of virtualization software (see Sorting out the different layers of virtualization for the Kusnetzky Group model of virtualization software.) Let's examine what desktop virtualization is and how it can be accomplished using several different types of software. Today's topic will be the role of application virtualization in desktop virtualization. We looked at the role access virtualization plays in the post Just what is “desktop virtualization” anyway? We'll look at the role of processing virtualization in a future post.

Defining desktop virtualization

To review, desktop virtualization is encapsulating and delivering either access to an entire information system environment or the environment itself to a remote device. This device may be based upon an entirely different hardware architecture than that used by the projected desktop environment. It may also be based upon an entirely different operating system as well.

Why should I care about this?

The first post in this series (referenced above) layed out the reasons that organizations should care about desktop virtualization. In short, desktop virtualization can be seen as a way to reach back to the past and provide a reliable, durable environment while still offering modern graphical applications.

How does virtualization software help?

How different types of virtualization technology can create a virtual desktop environment was laid out in the first post of this series. I won't bore you with it again. I'll bore you with something else this time.

The role of application virtualization

Application virtualization is using special tools to "encapsulate" an application allowing it to run in an enhanced way. The application may run in an isolated environment that makes it possible for an application to happily run in an environment that would create conflicts or problems. The encapsulated application may be copied to a system through the use of a simple file copy, installed perminately through the use of a typical software installation function, or streamed down to the remote system either in whole or in part. In all of these cases the application can easily be removed so that it may be reused on another remote system somewhere else without requiring the organization to purchase multiple application licenses.

Although somewhat less common, some form of parallelization might be applied to a computationally-intensive application. This would mean allowing the same application to run in parallel on several machines to reduce the time it takes to process a large amount of data.

Even less common is the use of a translation facility to make it possible for an application written for one operating system and for a specific hardware architecture to run in another environment. Transitive is one of the few companies that offers this capability today. It appears to me that Endeavors Technology is looking into how to make this work in a broad set of environments as well. I'm looking for announcements from them sometime in the medium future.

In all cases, the capsule containing the application does not contain an operating system! For this capsule to execute, the remote system must be running the appropriate operating system. If the capsule does contain an operating system, it would an example of processing virtualization rather than application virtualization. Processing virtualization's impact on desktop virtualization will be the topic of a future post.

A "connection broker" might be used to increase the levels of reliability and availability of application delivery. If one server becomes unavailable, the connection broker would simply reconnect the user to another server. As with access virtualization, unless some other form of technology, such as storage virtualization is in use, the user might have to restart a transaction.

This approach is a solution to the network access and network bandwidth problems. The application can simply be streamed down or copied to the remote device prior to it being "taken on the road." When a person is "off the grid", he/she can just use the encapsulated version.

AppStream, Altris Software Virtualization Solution, Citrix XenDesktop, LANDesk Application Virtualization, Microsoft SoftGrid, Trigence AE, VMware Thinstall, and Xenocode Virtual Application Studio are all approaches to application virtualization. There are many more but, I think that you get the picture.