A. One of the great benefits of application virtualization is the abstraction of an application from the OS by running all of the application's file system, registry, services, and other components in virtual layers inside the application's own virtual environment. This isolation means that virtualized applications can't directly communicate with other virtualized applications—the only interaction possible is via the system services such as COM, OLE, and cut and paste.
The communication via system services won't meet many types of application interaction requirements. Imagine a Java application: Having the Java Runtime Environment (JRE) as a separate virtualized application wouldn't work, you'd have actually have to package the JRE with every Java application you want to virtualize. This is a huge maintenance problem if you have 200 java applications, each with the JRE sequenced with the application. When you want to update the JRE, you have to update 200 virtualized applications. The solution to this has typically been to install the JRE locally on the OS, but then you lose the benefits of virtualized applications. This problem isn't restricted to Java—it's really any application that ties into another middleware type layer. For example, many CRM-type applications need to tie into Microsoft Office, but that wouldn't work in an App-V environment, because you'd have to sequence office with the CRM application.
(DSC is a new feature in App-V 4.5 that allows you to create dependencies between virtual applications and allows specific virtualized applications to directly communicate with other virtualized applications. You can now sequence the JRE as one virtualized application and then the Java applications as separate virtualized applications, and create a dependency on the JRE virtualized application for each Java application. This process allows the Java application to hook into the JRE and function correctly. You can have many virtualized applications that have dependencies on a single application or multiple virtualized applications, which gives you a lot of flexibility into how you virtualize applications and really streamlines your App-V applications, because they only need to contain application content, not dependencies.
In the example below, you can see CRM and Office applications sequenced as separate virtual applications. Because of this, the only interaction is via System Services, so the CRM application can't communicate directly with office and won't function correctly. When you use DSC to make Office a dependency of the CRM application, the CRM application can access the Office virtualized application environment and function correctly.
DSC also works great for plug-ins. I can virtualize a plug-in then create a dependency between the primary application and the plug-in, and the application will have access to the plug-in's functionality.
