I have previously written about inter-isolation communication and how it can be used to minimize the application maintenance for isolated applications.  That is, to retain the advantages of isolation while getting maintenance of isolated applications back on-par with maintenance of locally installed applications.  I have also written about the layers of glass which make the isolation possible.  The previous discussion of the layers of glass ignored IIC.  This post combines the layers of glass with IIC to show how IIC happens and how this allows separate maintenance of the various installation images that are run under isolation.

Refresher on Inter Isolation Communication

If you have multiple big applications, all of which also need the use of a small application, running under isolation says that you have to install the small application into each of the “big” applications.  If you later decide to update “small” application, then you have to update small application in ALL of the using profiles.

Compare that to a local machine installation where one installation of the small application effects all of the big applications.  That is handy, but it is also something that isolation systems try to avoid.  In a “completely isolated” world (Streaming Clients before XenApp 5.0/Streaming Client 1.2), the only choice was to install the small application into each of the big profiles.  You could put the small application outside of isolation and have it visible to all the big apps, but stick with me on the concept.  You want the small application (lets call it Adobe Reader) usable to each of the big applications, but you don’t want anything installed on the local machine.

Without IIC, you have to install Adobe Reader into each of the “big” profiles and this creates a situation where isolation produces MORE maintenance than does installing the applications locally.  Sure the local install case has opportunity for the apps to crater each other, but you still only have to install it once.  Generally, it is the “big apps” that are colliding with each other and this maintenance of the small applications becomes an isolation headache.

IIC gets isolated execution and locally installed back on the same “maintenance footprint”.  With IIC, you have ONE place to maitain the small application and updates applied to the single small application image automatically fold into the big applications at runtime.  PRETTY COOL STUFF!

How does it work

When having this as a goal, we considered a complex scheme to open COM and other communication holes in isolation spaces so that applications in different sandboxes can communicate across the sandboxes; honest to goodness INTER-isolation communication.  This becomes pretty complex when you consider how to define holes that should leak through and how to define where that should not occur.  You would also also wonder what you missed.

We cheated

Instead of defining complex communication between isolation spaces, we wrapped the SEPARATE isolation spaces into a single isolation space.   Now, you have separate MAINTENANCE of the “big” and “small” profiles, but they are runtime combined into a single image.  Notice that this eliminates all the complex stuff of defining holes between isolation spaces, because in reality, all the apps are running in the same isolation space; but they are separately maintined.

This decision requires an assumption that big-app and small-app already get along.  A safe assumption as millions of locally installed instalations already confirm that for the most part, these TWO applications get along.  We still want them separate from other applications and separate from the local machine, but as far as these applications go, we already know that they get along.

In many ways, this is moving the isolation bar to the left.  If right means isolate everything and left means isolate nothing, then the early isolation system was all the way on the right.  IIC moves it a bit back to the left, but in a measured manner that produces a good outcome at a reasonable cost.

Layers of glass

The classic layers of glass view shows 3 layers.  Here’s a diagram along with graphics that show how the bottom two layers are actually shared across all the users on the machine. 

IIC takes this to new depths!

There are really N layers of glass.  The parts in dark gray above which are marked Installation/Execution image are really deeper than 1 layer.   Each of the profiles that is part of an IIC profile provides 1 layer of the “installation root”.  Here’s a graphic.

Position matters!

I usuall title this “DLL Hell is back!”.  When viewed from above, the application sees the world through the mask of the layers between it and the real machine.  Each layer can add or DELETE registry and file system content and the layer at the top (the per-user layer) wins!  Beneath it, the top installation image wins in preference to the lower layers.  To avoid this, the Streaming Profiler allows the administrator to define the order of the layers of glass.  This is subtle, but occasionally it is important.  You’ll see “move up” and “move down” buttons in the profiler panel that lets you select existing profiles to be made part of this new profile.  The sub-profile at the top is the one that is highest in the layers of glass.

Generally speaking, the order of the installation images in an IIC profile doesn’t matter because any applications that the admin is putting together likely already work cleanly together.  The profiler UI is really there to accomodate the exception case.  The admin could just as easily cure the collision by deleting the offending content from all but one of the layers.  The one remaining will “shine through” all of the higher levels which do not have that same content.  Its still good to make it adjustable.

Making it adjustable also lets the admin put the “biggest” at the top.  Sometimes this isn’t possible, but if it is, putting the biggest at the top should provide more efficient execution as the isolation system will find things earlier.  It starts at the top and works it’s way down and if it finds things sooner, it runs faster.

There is no theoretical limit to the number of layers.  Anything beyond 5 starts to seem busted in concept, but the isolation system has no inherent limits to the number of layers.

Joe Nord

Citrix Systems