On-Boarding is the process of bringing the application to the operation. It's everything that needs to happen for hand-off of the app from the ISV to the hoster.
In the scenario described in the previous post, I mentioned that Northwind requires ISV to package the application in a specific way. The intention is of course to automate the process on their side as much as possible, avoiding as many manual steps as possible (no phone, no e-mails, nothing...)
NWH calls this a "Hosting Pack" and it will typically contain:
Notably, some assets are forbidden from the Pack: for example config files. Because config files contain deployment specific information (like server names, IP addresses, connection strings, etc.) NWH does not allow ISV to author the config files directly. They will be generated based on data center specific requirements.
The package is the input for the on-boarding system which is responsible for:
NWH doesn’t really care too much about the internal details of the application, as long as it follows the basic architecture described in their model. For example, communication between the web and the database is forbidden and it will be enforced at the network level.
NWH provides ISVs with a tool that allows them to author packages and has this rules built in to minimize the chances of mis configurations. Think of this a an "fx-cop" for on-boarding.
Figure 1: On-Boarding in Northwind Hosting
As I'm sure you imagined, a fundamental component in the Hosting Pack is the application manifest. The assets are the ingredients, but the manifest is the recipe. Without the recipe, you might not know very well what to do with the ingredients (except if it is garlic, which goes well on anything :-) )
Figure 2 shows a simplified view of NWH manifest.
Figure 2: Northwind Hosting Application Manifest
The manifest describes the entities that are significant for NWH for different reasons:
Let's pick up one notable entity in the manifest: The "Business Action".
A “Business Action” is simply an managed interaction between the web site and the web services. There’s 1:1 relationship between a Business Action and a WCF Operation, but not all Operations are Actions. Just those that need to be “managed” by the NWH. For example, because there’s a billable event associated with it or because there’s an attached SLA to it’s execution.
Next article, I'll focus on covering more details of these "Business Actions" in the context of Billing and SLA.