Dynamic Suite Composition (DSC)

One of our great team posted some information to the Technet Forum. A question was asked around contexting, which Lidiane (Lead PM) and Matt responded too. I have grabbed the main chucks of information around Dynamic Suite Composition (DSC) but you should read the whole thread!

 

The "contexting" feature we introduced in SoftGrid 4.5 is called Dynamic Suite Composition (DSC). The feature was designed to allow customers to package and manage Plug Ins/Add Ins and Middleware packages separately from the applications that use them.

If you have a Office 2003 package that was sequenced with a previous version of SoftGrid (say 4.1 or 4.2) you don't need to resequence that. You can now package the plug ins that you want your users to have access to separately. For example, today I sequenced the Office Converter Plug ing and added the dependency to my existing Office 2003 package by editing the OSD files of the Office 203 package. The "editing process" is simple, you add a dependency tag for each Plug In you want to add:

<DEPENDENCIES>

<CODEBASE HREF="....OfficeConverter.osd" .... >

<CODEBASE HREF="....ExcelTableMerge.osd"...>

</DEPENDENCIES>

You can certainly add more than 2 packages, and the really cool thing about it is that you can define permissions for each plug in separately. So, you could have 40 dependencies defined for Office but each user only has access to 4-5 plug ins at a time. So the users will only load and see the plug ins they were granted access to see. But the folks managing the Office package have an entire view of all of the plug ins that have been defined as dependencies in Office.

Given that, we DON'T recommend putting all of the plug ins in a single package because you will not be able to manage the users permission with the granularity that you may want to. Plus, if a patch comes out for your plug in, you don't have to impact any of the other plug ins.

The experience for the user should be exactly like it would be if the application was installed. In my example above, the Office Converter Plug In, there is nothing the user needs to know. He/she launches Excel 2003 and tries to open a Excel 2007 file. The plug in kicks off when its needed and the file opens, the user gets their task done without a problem or having to worry about any icons. If the plug in actually adds icons to the task bar or the Office ribbon, the icons will look exactly like they do if locally installed.

The same concept applies for middleware (i.e. JRE, .NET, OLEDB, etc). You can package JRE, .NET, etc on their own packages and define depedency on all of the applications that use them. You won't need to bundle them with a number of applications, you will be able to keep a single version of the middleware for all of your applications that use them. 

The applications will share a single virtual environment, so the applications can interact like they would if they were locally installed. That is the primary reason why we recommend this feature for plug ins and middleware, since those are not expected to conflict. If you intend to do anything larger, then you will need to do some testing prior to using it.

 

At this time there is not support for multiple levels of dependencies, you can actually set them up but they are ignored right now. 

So looking at your question if you had Office and an add-in that required Java, you would have to add Java into the dependecies as well as the add-in so it would be available.

As far as the variables, virtual registry, etc. it is my understanding that the secondary packages inherit the settings from the primary package, so whatever is in the primary OSD will be the only ones that are applied in that Virtual Environment.  In other words it doesn't actually look at the .OSD of the secondary.

<VIRTUALENV>

<DEPENDENCIES>

<CODEBASE HREF="PATH TO SFT",GUID="GUID OF PACKAGE", SYSGUARDFILE="CP FILE", SIZE="SIZE OF PACKAGE", MANDATORY="TRUE/FALSE"

</DEPENDENCIES>

</VIRTUALENV>

So to finalize we aren't actually pointing to the other osd, just pulling these specific settings out of the OSD for the secondary application.  Mandatory is the only one we can't copy out of the secondary OSD and it sets up whether or not this secondary is mandatory to load or the primary fails to load as well.

 

You would add permission per package in the management console. So, you would have the Office plug ins and Java packages in your server management console and you would give each individual package the appropriate permission. As Matt mentioned, the OSD is only used to get settings for the plug ins. The dependencies definition would only be in primary package (so for Office would have all of the dependencies, you wouldn't need to have them in the plug ins' OSD files).