Defining a Default Deployment from Application Designer

The standard sequence of events is to construct a System by drawing a system diagram using System Designer, and then evaluate that system against a logical datacenter using Deployment Designer. We describe that sequence of events in detail in the section "Defining and Deploying Systems."

There is a quick way to get started, which is to define a default deployment directly from Application Designer. We'll discuss that first, but keep in mind that this technique is intended only to allow for a quick evaluation of your deployment and, in this case, as a convenient way to introduce the concepts.

Important

Provided Files: The file StockBrokerSystemDeployment.zip contains a Visual Studio solution incorporating the application diagram (StockBrokerApplicationDesign.ad) and logical datacenter diagram (StockBrokerDatacenter .ldd) that you will need for this chapter.

With the StockBroker application diagram (StockBrokerApplicationDesign.ad) open, you can right-click an unpopulated region of the diagram and choose Define Deployment. You will be prompted for a logical datacenter diagram to deploy against, and you should choose the diagram StockBroker Datacenter .ldd, as shown in Figure 4-2.

Figure 4-2

The result will be a new deployment diagram with a default name like DefaultSystem1.dd, shown in the Solution Explorer within the Default System folder. Displayed, the diagram will look like what is shown in Figure 4-3.

Figure 4-3

That diagram looks rather like the logical datacenter diagram itself, doesn't it? If you look closely, however, you'll see that each server representation contains the instruction "drag an application from System View to bind," which is exactly what you'll do next.

The System View

The System View should appear automatically, and will provide the following list of applications grouped under the heading Default, which is the name of the default system into which the applications have been grouped:

• StockBroker

• MarketMaker

• StockQuoteApp

• DealingApp

• StockDatabase

• StockMarket

You will learn later how applications can be grouped more logically into systems of your choice, with names that are more meaningful than "default."

Important

If the System View does not appear automatically, you can display it at any time by right-clicking the deployment diagram and choosing System View.

Binding applications to servers

Given a deployment diagram (refer to Figure 4-3) and a set of applications grouped into systems (described previously), you can set about mapping the applications onto the servers. This mapping process is called binding and is performed simply by dragging applications from the System View onto the servers that will host them.

In general, logical servers may host applications as follows:

• An IISWebServer may host Web services, web applications, external Web services, or BizTalk Web services.

• A DatabaseServer may host ExternalDatabase applications.

• A WindowsClient may host Window applications.

• A GenericServer may host generic applications.

You can try out the binding process by dragging the applications onto the servers according to the following scheme:

• DealingApp application to be hosted by the CustomerDesktop

• StockMarket application to be hosted by the StockMarketServer

• MarketMaker application to be hosted by the MarketMakerServer

• StockDatabase to be hosted by the StockDatabaseServer (optional)

• StockBroker application to be hosted by the StockBrokerServer

• StockQuoteApp application to be hosted by the StockBrokerServer

The similarity between the application names and server names is simply for convenience and clarity in our example. Servers need not have names similar to the applications they host, and the binding of applications onto servers need not be one-to-one. That fact is demonstrated by our final bindings, which result in two applications—StockBroker and StockQuoteApp—being bound to a single server.

Note

You may want to observe that any number of systems may be bound to a single logical datacenter—a common real-world scenario. You not only bind each application to a server on which it is to be hosted, but also bind each of its endpoints to an endpoint on that logical server. In simple cases, where there is no ambiguity, this binding is automatic. If not, you must resolve the endpoint selection manually.

When you bind the StockMarket application to the StockMarketServer, a Bindings Details dialog box will ask you to choose one of the StockMarketServer's incoming server endpoints as the endpoint to which the application's StockPriceFeed endpoint should be bound. If you placed them initially without renaming them, your options will be ServerEndpoint1 or ServerEndpoint2. We bound to ServerEndpoint2, as the endpoint ultimately connected to the StockBrokerServer as a client.

Note

Obviously, you could be more meticulous about assigning meaningful names to all endpoints when constructing a logical datacenter diagram, or even rename the endpoints on the LDD immediately prior to using Deployment Designer.

When all of the applications have been bound, you will end up with what is shown in Figure 4-4.

Figure 4-4

In our list of bindings, we indicated the binding between the StockDatabase and the StockDatabaseServer as optional because you won't be able to perform that binding using the supplied files without first creating an ExternalDatabase in Application Designer. We have shown that binding in Figure 4-4, however, for completeness.

Prohibited bindings

As you experiment with Deployment Designer, you will find that in some cases you are prevented from binding an application to a server. This will be indicated by the cursor changing to a no-entry symbol and a message "Bind application to a compatible logical server."

If this occurs, you will have to check the compatibility of the applications and endpoints on your Application Diagram against the zones, servers, and endpoints on your Logical Datacenter Diagram. For example, you might have tried to bind a web application onto a server that is not an IISWebServer, or which does not have a WebSiteEndpoint. Or you might have used the Settings and Constraints Editor to constrain a web server to allow only external Web services to be hosted.

Validating the deployment

Once you have bound applications onto servers, you can then validate your deployment by right-clicking the diagram and choosing Validate Diagram. The settings and constraints specified in the system will be validated against the settings and constraints specified in the logical datacenter. Although we have successfully bound the applications to the datacenter definition, this does not imply that the configuration of the system and the datacenter are compatible. Please note that validation will confirm that connection pathways exist in the datacenter between the servers that you use to host applications connected in the system definition.

Note

We told you earlier about the interplay between settings in the application/system layer and constraints in the hosting layer, and vice-versa. In a nutshell, by defining constraints on the hosting layer (via the LDD) the operations analyst is saying to the application developers, "If you want to deploy in my data- center, your application systems must have settings that are compatible with the constraints I have set." The levying of requirements can go the other way as well. The application developer or architect can require that the datacenter have a hosting environment compatible with the requirements of the application (e.g., Windows Server 2003).

Validation errors, if any, will be displayed in the Error List window. You can double-click a validation error in the error list to navigate to the setting that violates the constraint.

Note

Thinking about the Team System in a wider sense, this situation might present an ideal opportunity to create a work item for the error, to ensure that it is addressed.

For demonstration, you can cause a validation error by following these steps:

1. Select the incoming StockBrokerWeb WebSiteEndpoint of the StockBrokerZone on the Logical Datacenter Diagram.

2. In the Settings and Constraints Editor, uncheck the WebServiceEndpoint constraint.

3. Validate the existing deployment diagram again by right-clicking the diagram and choosing Validate Diagram.

You will see the following validation error:

      The WebSiteEndpoint StockBrokerWeb can only host the following types:      WebContentEndpoint. 

Obviously, you can fix it by rechecking the WebServiceEndpoint constraint of the StockBrokerWeb endpoint in the Settings and Constraints Editor.

You can cause further validation errors simply by not binding some of the applications from the System View, as shown in the following example:

      The application StockMarket from system DEFAULT is not bound in the deployment      diagram DEFAULT1. 

Important

You can clear the validation errors from the error list by right-clicking the deployment diagram and choosing Clear Validation Messages. Be aware that this only clears the messages; it does not resolve the errors!

Differences between default deployments and system deployments

Having described how to create a default deployment directly from an application design, we will describe how to define systems as groups of applications for deployment. What's the difference?

As you saw, a default deployment always creates a default system, which has configurations and connections taken from the application diagram. Thus, the configuration and connections reflect your development environment, rather than the final system deployment, so this technique is most useful when the development environment and deployment environment are in fact identical. Even so, Microsoft recommends that you not use default deployments to finalize a deployment definition, even in the case of identical environments.

Microsoft's specific advice is as follows:

Note

"Finalizing a deployment definition from deployment diagrams or deployment reports generated from default systems is not recommended. Default systems are useful for quickly evaluating individual applications within the datacenter, but should not be used for final deployment. No system diagram (.sd) files are generated for default systems. Therefore, except for the information included in the deployment report, no record of the default system actually exists, for example, to check into source code control. It is recommended that you use deployment diagrams created using default systems to quickly evaluate applications for configuration and connection issues. You should then use System Designer to create your system designs and use these instead to create deployment diagrams and the corresponding deployment reports."

The default system mirrors the application diagram to the extent that if you change the applications and connections in Application Designer, these changes will be incorporated automatically in the default system. The application diagram mirrors the solution; there are several scenarios in which the solution diagram may contain more than you want to include in a system for deployment: test, test-service stubs, alternative applications (such as geographic variations of the same function that will be substituted in the system, depending on the target of the system), or functional elements that might be excluded, perhaps if defining a down-level configuration, perhaps as a down-level product. For deployments based on explicitly defined systems, you might need to incorporate changes in the application design manually in those systems. Specifically, what is not incorporated is the configuration of connections from the application diagram. Any underlying structural changes do get reflected in the system diagram by default—endpoints added or removed, for example, or the configuration of settings and constraints defined in the solution, which is considered part of the application definition.

With that in mind, we'll now demonstrate how to define systems explicitly.