Deployment Reports

In the preceding coverage of the System Designer and Deployment Designer, we haven't actually deployed anything. What we've done is evaluate the deployment of our application systems against the requirements of the logical datacenter. In order to deploy properly, we need a deployment report that describes what to deploy, where, and how.

Deployment Designer provides a Deployment Report feature, which produces a document containing SDM meta-data from the application and application hosting layers. This information tells you what software needs to be deployed where, and how the applications and hosts need to be configured to support the deployment.

Right-click a deployment diagram and choose Generate Deployment Report. Two new files will appear in Solution Explorer with the same names as the deployment diagram: an.html file (the human-readable version, discussed in the next section) and an.xml file (the machine-readable version, covered in the section "Machine-readable deployment reports and automated deployment").

Human-readable deployment reports

Generating a deployment report for the default system deployment (file DefaultSystem1.dd) that we created at the outset will result in a file named DefaultSystem11.html containing the deployment information as human-readable HTML.

Important

The companion file DefaultSystem1.xml is discussed in the next section.

The human-readable version comprises a number of sections that provide information on Errors (listed first to get your attention), Bindings (see Figure 4-10), the deployment diagram (identical to Figure 4-4), the logical datacenter diagram (the target of the deployment), systems (see Figure 4-11), and the system diagram (for the full suite of applications), followed by a number of sections describing the deployment resources in detail such as IIS6 settings.

Figure 4-10

Figure 4-11

Machine-readable deployment reports and automated deployment

What you achieved by using Deployment Designer is matching up the configurations of the applications and systems to be deployed with the hardware and software resources available to host them in the deployment environment. You also matched the logical resources referenced by the applications with the actual access points in the deployment environment.

Ultimately, we'd like to be able to use that model-based information to provision or configure resources on demand, and this aspiration is made feasible thanks to the XML version of the deployment report, which is not intended for human interpretation. Because the format is XML, it raises the possibility of transforming the output, using XSLT, into an in-house format suitable for generating an automated deployment script.

Important

Remember that where an automated deployment is neither possible nor desirable, the same deployment report may be generated as human-readable HTML.

The XML output can be very large (measured in megabytes), so it is impossible to list here in its entirety, but it's easy enough for you to reproduce as described. Figure 4-12, in which we have collapsed some of the XML elements to show the overall structure, gives you a feel for the information it contains.

Figure 4-12

You can see two XML tagged elements, <Applications> and <Binding>, that correspond with sections of the HTML report. If you could scroll down, you would see more such sections.

Within the <Applications> element is a <System> element (named Default because this is a report for our default deployment); and within the <System> element are <Application> elements representing each of the applications within that system. We have expanded the <Application> element corresponding with the StockQuoteApp so that you can see further details of the settings, resources, and endpoints of that application.

Within the <Binding> element, we have expanded the <Zone> element corresponding with the ClientZone so that you can see—among other things—that the CustomerDesktop logical server is contained within that zone.

To clarify the overall structure just described, and in case it's difficult to see that detail in Figure 4-12, here is a simplified version of that hierarchy:

      <Applications>        <System Name="Default">          <Application Name="DealingApp">          </Application>          <Application Name="StockBroker">          </Application>          <Application Name="MarketMaker">          </Application>          ...          <Application Name="StockQuoteApp">            ...            <Endpoint Name="StockQuoteService">          </Application>        </System>      </Applications>      <Binding>        <Zone Name="ClientZone">          <Endpoint Name="StockBrokerClientProxy">          <BoundLogicalServer Name="CustomerDesktop">      ... 

That should serve to whet your appetite to investigate further the syntax of the deployment reports. The point is that you—or more likely a third-party vendor—can devise tools that automate the deployment by interpreting and transforming the information contained therein.