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:
- The collection of assets that need to be installed in their data center (code, files, images, db scripts, etc). Everything needed to run and install the app
- A description of those assets, their relationships and other important information we’ll discuss below
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:
- Verifying the package integrity and consistency
- Verifying that the basic rules are followed (like no config files rule for example)
- Installing the package in a test environment for ISV approval
- Promotion of the package from the test environment to production
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:
- There are deployment considerations (e.g. the files to be deployed in a Web Site)
- Capacity planning & SLA management (expected response times for well know entry points to the app like web pages, web services, db size, etc)
- Billing management (Billable events associated with Operations)
- Customer support (who to contact in the ISV)
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.