This is the 3rd post in a series on Inter-Isolation Communication. I previously shown the layers of glass with IIC and how the streaming profiler can mount sub-profiles as a part of running an installer for a new profile. This post describes how ANY profile can be “sub” to another profile and how “profile trees” result that are potentially far deeper than one level.
Consider that before inter-isolation communication, administrators wanted to allow communication between sandboxes. They want to have two profiles that they know are good; but want the applications in those sandboxes to be able to talk at runtime. With inter-isolation communication, any profile can be part of an IIC profile. The existing profile can even be made with a profiler that had no idea what IIC was. The IIC supporting profiler and client first shipped with XenApp 5.0 (Streaming Client 1.2), but the profiler/client at this level can define IIC links to profiles created at earlier levels.
It is easy to consider that an IIC profile links 2 or more sub-profiles. What is not so obvious is that IIC profiles may themselves be the item that is linked. That is, the IIC profile may be the “linkee” rather than the “linker”.
Consider this graphic
It is much to consider, but “TOP” is a dependent profile that links to 3 other profiles. As TOP has its own isolation target, the profiler will mount everything underneath as a part of running the profiling activity to support creation of the Target at top. The profiler supports setting the relative height of isoaltion spaces within a profile, so the order of A, B and C can be adjusted. The layers of B1 and B2 though are defined as part of profile B and must be adjusted at that level.
Configuration of the profiles
A.profile may have come from an ealier version of the streaming system, where it did not know about IIC.
B.profile is “links only” and this means that it was created with the IIC supporting streaming profiler and since it is an associative profile, it is merely “pointers” to the dependent profiles, which are B1 and B2.
C.profile is very much like TOP. It mounts the C1 profile and then C has a produced execution target of its own which is the result of running installation activities while editing C.
Eventually, TOP exists and all of this stuff is stored on an Application Hub, somewhere on your network.
NOTE: All profile links are by name only and are required to be on the same application hub/file server. This is on-purpose so that all links are “relative” and the profile content can be moved from one server to another without having to edit any of the profile information.
When publishing applications, the Access Management Console will open TOP.profile and will present a set of applications for publishing which is the SET UNION of all of the sub-profiles. It is possible that you want to publish all of the applications, but possibly more likely that you want to publish a subset. Either way, as the administrator, you have the full set available for selection and it doesn’t matter which target provides the initial executable.
That pretty much puts it all together. This stuff has been out for a while, its complex – but powerful.