SOA application installation best practice: sigle installer or few separate MSI?

Question

I have an application which consists of 2 web sites, 3 Windows services (2 of them hosts WCF services) and 3 SQL databases.

It's likely that all system will be installed on 1 or 2 servers, but also possible that some services will be installed on separate machines if performance will be seriously affected by them.

I need to create WIX installer for all this staff. The thing is I'm not sure if it would be better to create single complicated installer which will be able to install whatever component set (some services may be installe), or few separate installers.

Single-installer approach has important advantage if the whole product is installed on the same machine - we will need only few dialogs shown to user and we will be able to setup connection configurations between components automatically. But of course development of such installer is very complicated: installer wizard pages should be shown based on features, installing currently on machine. There will be multiple conditions and testing all them will be a hell.

Multiple-installer approach is easier to implement and test. But of course it will be harder for user to install the product - he needs to set same service installation URLs few times (once per installer) - to setup connection configurations to WCF services.

I searched for best-practices in this area but looks like there is not a lot of information. Can anybody suggest which way is more appropriate?

Answer 1

If you design it correctly you can switch back and forth between the two approaches. Personally I've used InstallShield which has a feature called RELEASE flags and Product Configurations. It's basically a way of defining multiple builds that pull in different features and apply different branding (ProductName, ProductVersion, ProductCode, UpgradeCode, INSTALLDIR and so on.) This is how you'd make say a multiple single product installations and then build it again as a product family suite. This pattern applies to SOA very much. The same thing could be done in WiX using preprocessor statements to control compilation.

I once worked for a company that made an SOA based server product. The system had 26 installers of 5 catagories ( Win Client, Mobile Client, Service Layer, Web UI layer and SSRS Reports) I did each as it's own installer and it really helped cut down on the complexity. Each service had it's own database which made writing the SQL scripts to create and update the DB a lot easier. It also cut down on the amount of configuration each installation had to do since it only had to know how to set itself up and the other piece it communicated with.

The bootstrapper to bring all these pieces together may or may not be needed. Part of the reason we choose SOA is to give us complete control on how to scale the system out. This type of flexibility (26 pieces on 1 server, 1 piece on 26 servers, 2 tiers, 3 tiers, n tiers ) makes it difficult to encapsulate through a simple wizard UI.

Answer 2

I would go with multiple installers, bundled into a big single installer, this allows you to easily separate and test them. The bundle installer has the purpose of capturing the data from the user a single time and pass it to all installers selected for installation.

You can do this using Burn support from Wix or other setup authoring tools (that provide you with a GUI, allowing you create the projects and dialogs much easily). Wix is a very good tool, but the time you need to create the projects is too much, compared with the costs of a license for a good setup authoring tool that provides and drag and drop IDE to design dialogs and chain the installation of the separate installers.

EDIT

To pass values from the bootstrapper to the background installers is very easy, you don't need to write any custom code. This is handled directly from the setup authoring tool. All you need to do is to make sure the tool is capable to create Windows Installer compliant packages. This way, you can pass the selections made from the user to the background installers as property values, in the command lines of the installers.

The bootstrapper installer should not register with Windows Installer, so it does not appear in Control Panel, as a separate applications, there you should see only the separate background installers.

Answer 3

I'm providing a second answer to give a different perspective from my first. Microsoft Team Foundation Server installation is 1 single installer for different roles. You can scale out the various layers of the system but the install is all the same: install it all.

What they have chosen instead is to invest in a role configuration wizard that gets executed post installation to activate a given installed feature and configure it's settings and that of the next layer it needs to communicate with.

This is a very good way to go also.