In addition to creating a high-level picture of a logical datacenter, you can also dig deeper into the specific settings and constraints for the individual servers and endpoints. The constraints will ultimately determine the kinds of applications that may be bound to specific servers, the communication pathways that are allowed between servers, and the policy specifying which kinds of traffic can pass along those communication pathways.
This discussion moves us away from the core topic of visual design and into the realms of, for example, IIS configuration. While it's not possible to step you through every setting and constraint—there are tens if not hundreds of them—we can at least show you how to access the Settings and Constraints window to give you an idea of what you'll see there.
You can right-click any server and choose Settings and Constraints to invoke the Settings and Constraints window. We'll do that for a GenericServer (as the simplest case), for an IISWebServer (as a more complex case), and, to show it's not limited to servers, for a WebSiteEndpoint and a ZoneEndpoint.
For completeness, we should tell you that you can also access the settings and constraints for zones, not just their endpoints. Zone constraints determine which types of servers you can add to a zone.
Before we access the settings and constraints specific to our example, we'll first say a few words about the important relationship between settings and constraints, and the interplay between the two.
Constraints are created in one layer against settings in another layer. For example, constraints can be set from the application layer (using Application Designer) against settings on the hosting layer (the Logical Datacenter) and vice versa. The idea is that the operations team can constrain the application layer while allowing the developers to request a set of features in the target deployment environment. The operations team may or may not decide to accommodate those requests in the logical datacenter.
To see an example of this interplay between settings and constraints, you can view the settings of the StockBrokerServer in the logical datacenter diagram, and then compare them with the constraints of the StockBroker application in the Application Diagram. You will notice that where the StockBrokerServer has a setting for the operating system, the StockBroker application has a matching constraint.
A constraint is a requirement that must be met by an application deployed on a particular logical server.
The Settings and Constraints Editor provides control over predefined constraints and user-defined constraints, both of which you'll see as our discussion progresses. A third kind of constraints—implicit constraints—are inherent in the elements placed on the diagram from the toolbox. These cannot be edited using the Settings and Constraints Editor but may be authored using the System Definition Model SDK.
Figure 3-8 shows the Settings and Constraints window for a generic server—actually, the StockMarketServer of our example. Note that there are no predefined settings for a generic server, and the only available constraint is whether or not (checked or unchecked) this generic server can host a generic application.
The constraints determine what kinds of applications you can bind to servers using Deployment Designer, which you'll meet in the next chapter. For a generic server, the only kind of application you can bind—if you check the box—is a generic application.
The generic server exposes the simplest grouping of settings and constraints, which is why we covered that one first.
An IISWebServer enables a richer set of settings and constraints to be specified—so many that we couldn't cover the complete set in any detail without moving away from the core topic of visual design and into the realm of IIS configuration. We can at least provide a starting point in terms of how and where to manipulate these settings, and in this case we'll consider the two aspects—the setting and the constraints—separately.
Figure 3-9 shows a subset of the constraints for an IISWebServer—actually, the StockBrokerServer of our ongoing example.
As you can see, several checkboxes are provided so that you can constrain the server to host any combination of ASP .NET services and applications, External BizTalk Web services, and External Web services. In Figure 3-9, we have expanded the ASP .NETWebApplication so that you can see the additional constraints that may be specified. For illustration, we have checked the ASP .NET Session State box, thereby enabling us in the main pane to further specify the Session State Mode as SQLServer and the HttpCookie Mode as Auto Detect.
Figure 3-10 shows a subset of the settings for an IISWebServer—once again the StockBrokerServer of our ongoing example.
In Figure 3-10, the InternetInformationServices WebSites category has been selected, thereby enabling us to specify settings for the operation of the IIS HTTP server. In the main pane, we've expanded the Content category in order to set up MimeMap for the allowable MIME types to be handled by the server.
Look in the IIS documentation for more information about the effect of configuring various settings, along with how those settings are stored in Metabase.
Settings and constraints are not limited to servers, so you can also specify these for an endpoint—such as WebSiteEndpoints—as we have in Figure 3-11.
We have expanded the Content subcategory within the main pane in order to show the correspondence between this setting on the WebSiteEndpoint and the same setting on the IISWebServer shown earlier. Effectively, a WebSiteEndpoint provides a subset of the settings and constraints for an IISWebServer.
You can constrain this kind of endpoint to be a WebSiteEndpoint (obviously) and to handle web content. What effect might this have? Well, an HTTPClientEndpoint constrained to allow only web content traffic cannot be bound to a WebSiteEndpoint configured to allow only Web service traffic.
To complete the picture regarding settings and constraints, we'll consider zone endpoints. Figure 3-12 shows how a zone endpoint may be constrained.
Notice that the WebSiteEndpoint checkbox allows the zone endpoint to accept communications to an internal WebSiteEndpoint if checked. The zone endpoint may also allow for communication to an internal DatabaseServerEndpoint if that box is checked.
The settings and constraints we've just considered are predefined. In addition to those, you can define your own custom settings and user-defined constraints.
You can create custom settings for zones, endpoints, applications, systems, and logical servers in order to provide additional meta-data about your development or deployment environment.
To create a custom setting:
Select the zone, endpoint, application, system, or server for which you want to provide the custom setting.
In the Settings and Constraints Editor, expand the Settings node, right-click Custom, and choose Add Custom Settings.
Enter the required information in the Custom Settings dialog box that appears.
As a concrete example, you could create a new setting that specifies a server as being "Test" or "Live" by populating the fields as follows:
Note that we chose "OurCompanySpecific" as the category in order to group this setting with other company-specific settings. You could choose another category or leave that field blank.
Custom settings cannot be used to define constraints, so when checking the User Defined (constraints) checkbox—described in the next section—you will not be able to gain access to settings that you have defined as described here. However, custom settings can be used in custom deployment scripts because they are captured in the deployment report; and unlike other settings, custom settings can be displayed in the Properties window.
User-defined constraints enable you to specify constraints that fall outside the group of predefined constraints. Because constraints are the counterpart of settings, which they constrain, you can specify them from the available pool of settings.
An example given in the Visual Studio 2005 documentation is that of HTTP KeepAlive functionality, for which there is no predefined constraint. You can author a user-defined constraint for the connection settings on the website, and you can specify for that constraint a custom error message and a help URL.
You can create a user-defined constraint as follows:
Select the application or logical server for which you want to define the constraint.
Open the Settings and Constraints Editor.
Select the User Defined checkbox.
In the tree view under User Defined, select additional checkboxes as needed to specify groups of settings to include in the constraint.
For each group of settings, select the checkbox for individual settings to include in the constraint.
Enter setting values in the Value column.
For each setting value, you have the option to specify a custom error message that will appear if the constraint fails as a result of this setting. To set a custom error message:
Under Error Message, click the ellipsis. The Error Text dialog box appears.
Enter the text of the custom error message using the macros provided to enter placeholders for items such as setting name, required value, Help URL, and current value.
Click OK to set the custom error message.
The full text of the custom error message will include the text specified for the error message, including the Help URL if you added it to the error message text using the Help URL macro.
It can be difficult to manage the overwhelming number of settings that are available, so help is at hand in the form of the Import IIS Settings Wizard. This wizard guides you through the process of importing settings from an existing IISWebServer into an IISWebServer shown in Logical Datacenter Designer.
You launch the wizard by right-clicking an IISWebServer on the diagram and choosing Import Settings. Using the various checkboxes, you can choose to import the web server global configuration, applications pools, plus the settings for already deployed websites. In the latter case, each will become a new endpoint on the server.