Tools for Architects

Tools for Architects

The design and development of distributed systems is more complex now than ever. Architects need new ways of reducing this complexity to increase the predictability of deployment. To do this, they must find new techniques for diagramming these systems by using rich metadata about both the design and the deployment's operational requirements.

Ask yourself this: how many times has the IT operations team locked down the servers or implemented restrictive group policies that lessened your application's chance of deployment? What usually ends up happening? The result is compromise during crunch time—which isn't good. On the other end of the spectrum, the IT group could inundate the developers with paperwork or meetings, outlining every service pack, version, and configuration of their datacenter. This, too, is counterproductive. What the developers want to know is whether Microsoft SQL Server™ will work and whether their ASP.NET Web services will be able to access it!

The best solution is to have application architects communicate their designs effectively to the IT operations team and to have infrastructure architects and operations communicate information about their hosting environments back to the developers.

NOTE
Team System doesn't make the distinction between application architects and infrastructure architects. It's important, however, to separate them into two subroles because one group will know Web services, Web applications, and Windows applications and the other group will know ports, perimeter networks, firewalls, security boundaries, and server configurations. Maybe in your organization this is one person, or maybe it's several people.

One thing is clear: architects' needs are different from the needs of project managers. Architects have a need for intuitive design tools that can allow them to achieve productivity, such as generating code. These types of tools are called the Distributed System Designers and are provided solely by Visual Studio 2005 Team Edition for Architects. Using these tools, architects can create one of the following Distributed Application Diagrams (DAD):

• Application diagrams—Represent applications that provide or use services

• Logical Datacenter diagrams—Represent interconnected logical servers that symbolize the logical structure of a datacenter

• Deployment diagrams—Represent the deployment of a specific system into a specific logical datacenter

• System diagrams—Represent application systems, which are composed from other application diagrams

These diagrams, like any good model, tell a story to other team members who might not share the same level of expertise as the architect. Communication with other members of the team, as well as to nontechnical stakeholders of a project, is important, and pictures improve the chances of effective communication taking place. This communication can lead to better collaboration and an increased predictability of success of the project. For example, if a team's architect can accurately diagram the network infrastructure and then demonstrate how the project's application will deploy successfully onto the servers, the operational staff's worries can be alleviated.

What's better is that these architectural diagrams are created in a visual environment, which is interesting and captivates its users. It also tracks just the right amount of information, which has always been the goal of a good model-driven approach. In the past, a big problem with modeling tools has been that they've been very good at documentation but not very helpful for the actual development, deployment, and management of systems. When used properly, Team System realizes all these goals.

Dynamic Systems Initiative (DSI)

A major new initiative by Microsoft and other industry partners, such as Sun Microsystems and Siebel Software, is the Dynamic Systems Initiative (DSI). The goal of DSI is to reduce complexity while increasing communication flow. It's a way to design for the eventuality of a piece of software being deployed or, put another way, to design for operations. A key feature of DSI is its visualization of the systems and services and tracking the metadata about each to properly describe it to another system or service. This metadata will allow for one diagram to validate against another, and for the reasons I just mentioned, it's important for application architects to validate their application design against an infrastructure architect's datacenter design.

NOTE
Another key factor of DSI designs is that they're always kept up to date. Achieving this level of accuracy depends greatly on the tool and the commitment of the user; but, if the diagrams are not kept up to date, the validation can be worthless.

DSI is geared toward ensuring that the design is correct the first time and that it will deploy into the host environment successfully. But it's more than that—DSI also aims to capture knowledge and lessons learned once an application gets deployed and to apply that knowledge for easier ongoing maintenance. To achieve this, the industry is working to find new techniques for describing these systems using rich metadata about the design, development, deployment, and operational requirements that can be understood and exchanged by various automation tools.

This all sounds great. So where does most of the effort need to occur? Domain experts in various software development areas will need to brainstorm and capture the important metadata about a particular component. This metadata includes settings, constraints, versions, modes, security—in short, everything. Think of the effort as creating a schema (database or XML, whichever one comes to mind when you hear the word schema) to describe every type of operating system, application server, and Web server, as well as every major type of application or service that you can build with .NET.

All these DSI models need to be boiled down to common terms or interfaces so that, for example, the settings of a .NET Web Service can be validated against the policy restriction of its deployment environment. As more systems can be fully described using the DSI approach, many more possibilities emerge for building true automation into the entire software development life cycle.

NOTE
You've probably heard about the futurists who want to give every device in your home or office its own IP address. DSI can be thought of as being similarly aggressive because the DSI visionaries, of whom I am one, would love to have DSI eventually describe every type of system, service, and server in use!

System Definition Model (SDM)

Microsoft's initial DSI offering will surface in Team System. The implementation of this offering will be known as the System Definition Model (SDM). SDM classifies your application and its deployment environment into layers, much the same way that the Open System Interconnection (OSI) model describes a network stack. SDM offers the following benefits:

• Provides a common language to describe the design and configuration for all aspects of a distributed system

• Provides familiar abstractions that make it possible for application and infrastructure architects to communicate on common ground

• Makes it possible for application architects and developers to communicate application requirements in the run-time environment

• Makes it possible for infrastructure architects to communicate application runtime, security, and connectivity requirements that result from policies defined in the deployment environment

SDM defines the following layers (from the top down):

• Application

• Application Hosting

• Logical Machines and Network Topology

• Hardware

Distributed System Designers store SDM information in XML-formatted documents. In addition to this data, SDM documents can also contain graphical information for diagram items and extended data definitions. You can use Distributed System Designers to create and maintain a set of interrelated diagrams and documents that are based on the SDM documents. Typically, the definitions created in one document (for example, application definitions) are referenced by other documents.

Visual Studio Team Edition for Architects includes a solution template that makes it possible for you to create a distributed system solution, which makes Distributed System Designers available for you to design, configure, connect, and evaluate deployment for applications and application systems. As you go through this process, a distributed system solution typically contains or will contain the following items:

• A single application diagram (.ad file)

• One or more system diagrams (.sd files)

• One or more logical datacenter diagrams (.ldd files)

• One or more deployment diagrams (.dd files)

• SDM documents (.sdm files) for externally implemented application definitions

• Projects containing code files, configuration files, other related files, and SDM documents for internally implemented application definitions

Microsoft has a strong commitment to SDM. Visual Studio's SDM integration will continue to improve as we move into Orcas, which is the next version of .NET and Visual Studio. However, the SDM platform also applies to Windows directly, especially going forward into Windows Vista (formerly known as Windows Longhorn). This maturing SDM platform will facilitate the design, deployment, and ongoing operations of systems in Windows, not just Visual Studio.

Critical to this success is for each product team to build an adapter that other teams will depend on for design-time validation. The obvious winners here will be Systems Management Server (SMS) and Microsoft Operations Manager (MOM), which could both leverage SDM to make integrators' and administrators' jobs easier.

NOTE
If you're an independent software vendor (ISV), check back regularly for the software development kits (SDKs) and application programming interfaces (APIs) to help build cool SDM tools for Windows. You should bookmark the main Visual Studio Team System site: http://msdn.microsoft.com/teamsystem.

SDM SDK

You can download and use Microsoft's SDM SDK to extend the Distributed System Designers in Visual Studio 2005 Team Architect by adding new application, logical server, and endpoint types, as well as additional resources and constraints. You can also add relationships among new and existing concepts.

SDM systems can be used to model types of applications and logical servers. Application models can then be used within Application Designer. These SDM application systems can contain all other SDM building blocks, including SDM resources, endpoints, settings, and other SDM systems. You can author a logical server system that models a server configuration and can be used in Logical Datacenter Designer. The logical server can model hosting SDM application systems and contain settings, endpoints, and resources. By containing endpoints, the logical server system can have communication relationships with other systems. You can create settings on the logical server system that model the behavior of a real server, such as the minimum version of an application or an OS that the server will host.

The SDM SDK provides three command-line tools:

• SDM Command Line Compiler (SdmC.exe)—Responsible for validating the correctness of an .sdm file according to the SystemDefinitionModel Schema

• SDM Manager Generator (SdmG.exe)—An SDK tool that helps developers to build abstract SDM models for use with Visual Studio 2005

• SDM Prototype Generator (ProtoGen.exe)—Generates an initial Distributed System Designer prototype file for an abstract type

NOTE
The SDM SDK is part of the Team System SDK.

Domain-Specific Languages

With Team System, Microsoft takes a model-driven approach to software development. Some would refer to this as visual engineering. Microsoft, as well as many others in the industry, realize that Unified Modeling Language (UML) tools can take you only so far. UML-class diagrams, for example, don't support many .NET data types or such concepts as properties or static methods on interfaces. You don't see these limitations when you're drawing pictures and printing collateral to hang on your wall, but when it comes to generating code, you'll have to do some tweaking if you stick with UML. What productive .NET development teams require are Domain-Specific Language (DSL) tools that are more agile and precisely target the domain in question without any abstraction or the need for tweaks.

NOTE
Microsoft did some research in this area. It asked many developers who use UML which of the standard models they used. As you can guess, use cases were the most popular. After that, it was sequence diagrams. Beyond that, only a small group of developers delved into the other model types.

Before you ask, let me just say, “No, UML is not dead, nor is it going away any time soon.” As far as Microsoft's tools go, you can still use Visio for your UML needs, including creating the popular use-case and sequence diagrams.

What Happened to Visio?

This is a very common question. The answer is this: nothing has happened to Visio. In fact, Visio 2003 Professional remains a great way to create UML, Object-Role Modeling (ORM), and network diagrams, all of which complement Team System nicely. Team System's distributed application designers are intended to build very domain-specific, intelligent documents that can interact and be validated against each other. Visio's documents remain fairly static, with only some of them being able to generate code; however, because they are file-based diagrams, they can be uploaded to the Project Portal and referenced by the entire team.

Visio for Enterprise Architects is included in Visual Studio Team Edition for Software Architects and Visual Studio Team Suite. In addition to all the features in Microsoft Office Visio Professional 2003, with Visio for Enterprise Architects you can perform roundtrip engineering on software with the UML Model diagram and on databases with the Database, ER, and ORM Source Model diagrams. Visio for Enterprise Architects is a separate program from Visual Studio.

Here is an example of how you might use the UML support in Visio with your Team System environment:

1. Launch Visio Professional 2003.

2. Create use-case, sequence, and other UML diagrams.

3. Create your class diagrams using UML notation.

4. From Visio, generate C# or Microsoft Visual Basic® .NET code from the class diagrams you created.

5. Add the code files you generated to your Visual Studio 2005 project.

6. Open a class in the Class Designer (which is a new DSL tool).

7. Fine-tune the class for .NET.

NOTE
If you have Visual Studio Team System for Software Architects or Visual Studio Team Suite and also installed the version of Visio for Enterprise Architects included in those programs, you can create a Visio UML diagram from within Visual Studio. To do this, you will need to create a UML diagram from Visual Studio by opening the project you want to reverse engineer into a Visio UML diagram and selecting Reverse Engineer under the Project—Visio UML menu. Visio will launch to complete the reverse engineering, and you will be prompted with a Save dialog box, in which you can choose an alternative location or rename the diagram prior to saving it.

DSL Tools in Team System

The DSL tools in Team System include the Class Designer (which you will read about later in this chapter in the section “Tools for Developers”) and the Distributed System Designers. Regardless of the designer, the tools have a common set of features, such as continuous synchronization and a design-first approach that are tied together by SDM. These tools are the topic of the following sections.

Logical Datacenter Designer

Network and other topology diagrams have historically been of little value to developers or a development effort. In keeping with the principles of SDM, however, the Logical Datacenter Designer will allow network/infrastructure architects to create diagrams of their deployment environments that are more than just pretty pictures. The SDM diagrams will contain important metadata, such as constraints for application architects to test-deploy their applications against. These diagrams are an abstraction of the physical environment—hence the term logical. The server prototypes that the architect drags and drops will represent server roles in an actual deployment, so any constraints and settings placed on these servers should be general.

Using the Logical Datacenter Designer, you can create a logical representation of your datacenter. Logical Datacenter Designer enables you to model the placement and connectivity of logical servers and Zones. The logical datacenter diagram provides a logical, rather than a physical representation of the target datacenter. As a result, a physical server with Microsoft Windows Server™ 2003, Internet Information Services (IIS) 6.0, and SQL Server would be represented by three logical servers.

Logical datacenter diagrams can contain the following logical servers:

• WindowsClient

  A rich .NET Windows client

• IISWebServer

  An Internet Information Server (IIS) that can run an ASP.NET Web application or service

• DatabaseServer

  A SQL server

• GenericServer

  Any other server, such as Microsoft BizTalk®, COM+, MSMQ, Exchange, or another, non-Microsoft server

These logical servers can be placed in Zones. A Zone is defined as a kind of boundary, such as a firewall, cluster, domain, or other security boundary. Zones and the logical servers that they contain are subject to communication constraints that are specified on Zone endpoints. Zones are a nice way to place servers in a logical group. Zones can also have metadata and constraints. Figure 3-8 shows logical servers placed into Zones.

Figure 3-8 Logical servers grouped into Zones

NOTE
One limitation of a logical datacenter diagram is that they do not support firewalls directly. As the designer, you must use Zones to separate the public and private areas of your network, configure the information flow directions and security of your endpoints, and then add appropriate comments and notes to the diagram to indicate that there is a firewall there.

After dragging and dropping the Zones and logical servers and arranging them appropriately, infrastructure architects will want to set the appropriate settings and constraints. This will ensure that only the correct type of service, version, and security are allowed onto each of their boxes. This process is a way for infrastructure architects to define the policies of their datacenter.

This documentation will become evident when a deployment report is generated. More important, these settings and constraints are required to implement SDM. Application architects can immediately see what the requirements and restrictions are for their software.

Here are some examples of types of settings and constraints:

Zone Constraints

This type of constraint defines the following characteristics:

• The type of logical server that can exist within the Zone

• Versions of .NET runtime that can exist on the servers within the Zone

• Whether there is support for the global assembly cache (GAC) on the servers within the Zone

• IIS settings, such as application-pool restrictions on the servers within the Zone

• Whether the Zone can contain other Zones

Windows Client Constraints

This type of constraint defines the following characteristics:

• Whether the client can run Office applications

• Whether the client can run other generic or Windows applications

Windows Client Settings

These settings define the following characteristics:

• Operating system type, version, build, and service pack (see Figure 3-9)

• Application name and path

• Version of the .NET runtime

• Whether there is a need for the GAC

Figure 3-9 Configuring operating system settings

IIS Web Server Constraints

This type of constraint defines the following characteristics:

• The type of application (ASP.NET, BizTalk, external Web application, or other generic application)

• Whether the ASP.NET application requires membership support and related settings

• The type of ASP.NET security (none, forms, Passport, or Windows) and related settings

• The type of ASP.NET session state (off, in-process, state server, SQL server, or custom) and related settings

• Other ASP.NET Web server settings the target application must specify in order to run on this server

IIS Web Server Settings

These settings define the following characteristics:

• IIS server settings, including application pools, Web sites, and their endpoints

• Operating system type, version, build, and service pack

• Application name and path

• Version of the .NET runtime

• Whether there is a need for the GAC

Database Server and Generic Server Constraints

This type of constraint defines the following characteristic:

• The type of application that can be installed on this logical server (external database or generic application)

Custom Settings

Each server type and Zone shape allows you to specify custom settings so that you can track any additional metadata. Figure 3-10 shows an example of a custom setting for a Zone, which specifies that each server placed in the Zone must pass the Baseline Security Analyzer test. This test is a security diagnostics utility that you can obtain free from Microsoft. It tests the integrity and security best practices of most of Microsoft's popular servers.

The final step in designing logical datacenters is to connect the endpoints of the various shapes: Zones to Zones, servers to servers, and servers to Zones. You can think of these endpoints as representing physical ports or communication pathways. These connections convey a workflow of information. They also form another constraint check: consumer endpoint types have to match provider endpoint types for the connection to be allowed. This requirement will keep you from connecting to your database server over port 80 as an HTTP consumer when you really need to connect as a Tabular Data Stream (TDS) consumer using port 1433.

Figure 3-10 Creating a custom setting

NOTE
You'll need to forget for a moment that SQL Server 2005, the database of choice for building Team System applications, now supports direct connection over HTTP. Maybe the Logical Datacenter Designer will become aware of this fact in a later release.

Here's another example. Let's say you have two shapes on your design surface: an IISWebServer and a DatabaseServer. By default, the outbound client/consumer endpoint on the IISWebServer shape is an HTTP type endpoint, so you cannot connect it to the inbound provider endpoint on the DatabaseServer, which is expecting a different protocol. The solution here is to right-click IISWebServer, add a new client endpoint (as shown in Figure 3-11), and then connect the two endpoints.

Figure 3-11 Adding a new client endpoint

You'll learn more about the Logical Datacenter Designer in Chapter 5.

Application Designer

Application architects are accustomed to walking up to a whiteboard and diagramming their applications. The diagram usually consists of some squares, some text, and some lines connecting the squares and the text. If these artists are lucky, the whiteboard has the ability to e-mail or print the drawing for later reference. Or maybe someone nearby has a digital camera. The Team System Application Designer provides what I like to call “an intelligent whiteboard,” which allows the architect to drag and drop services and applications onto the design surface, configure settings, and then connect the applications and services. If that were all it did, you'd probably call it Visio. Team System, however, is superior to the whiteboard and Visio in several areas: it's a permanent, updateable, version-controlled document part of the team project.

• It can be test-deployed against one or more logical datacenters, with validation.

• It can generate code for the developers to begin implementing the services.

• It can generate a deployment report for the IT operations team.

• It can be saved to the toolbox or as individual systems for reuse in later diagrams.

• It looks really, really nice. (See Figure 3-12.)

Figure 3-12 A sample application diagram

Application diagrams can contain the following application and service types:

• WindowsApplication

  A .NET Windows forms application

• ASP.NETWebService

  An ASP.NET XML Web service

• ASP.NETWebApplication

  An ASP.NET Web forms application

• OfficeApplication

  A Visual Studio Tools for Office (VSTO) application

• ExternalWebService

  A non-ASP.NET Web service (a Web Services Description Language document)

• ExternalDatabase

  Any database or database server

• BizTalkWebService

  A BizTalk orchestration exposed as a Web service

• GenericApplication

  Any other application that isn't already mentioned in this list

TIP
A Distributed System Solutions project can contain only one application diagram. If you need to combine information from two diagrams, you'll have to create a second solution, add the application diagram, and then copy and paste the content back into the original application diagram.

After the diagram is built and arranged nicely, the application architect needs to set the appropriate settings and constraints on his or her applications and services. This will document and communicate any special requirements to Team System. This documentation will also surface when a deployment report is generated. More important, these settings are used during test deployment to validate the application design against a predefined logical datacenter diagram, as I've been mentioning throughout this chapter.

For example, if the application architect defines an ASP.NET Web Service that requires version 2.0 of the .NET Framework, this service won't deploy to a server that the infrastructure architect defined to support only version 1.1. When the deployment is validated, this conflict will appear as a validation error, and a resolution will be required. Better to find out about it now, during the early stages of the project!

Here are some examples of types of settings and constraints:

WindowsClient, OfficeApplication Constraints

These types of constraints define the following characteristics:

• Operating system type, version, build, and service pack

• Version of the .NET runtime

• Application name and path

ASP.NETWebService and ASP.NETWebApplication Constraints

These types of constraints define the following characteristics:

• Operating system type, version, build, and service pack

• Version of the .NET runtime

• IIS settings, including application-pool settings

ExternalWebService or BizTalkWebService Settings

These types of settings are provided by the Web Services Description Language (WSDL) document, which Visual Studio prompts you for in a familiar fashion. (See Figure 3-13.)

Figure 3-13 Dropping an ExternalWebService or BizTalkWebService prompts you for the WSDL document through Visual Studio's standard Add Web Reference dialog window

GenericApplication Constraints

These types of constraints define the following characteristics:

• Whether the application is a DatabaseServer, GenericServer, IISWebServer, or WindowsClient application

• Operating system type, version, build, and service pack

• Version of the .NET runtime

TIP
If your diagram contains both ASP.NET Web Services and ASP.NET Web Applications, the designer will name them “WebApplicationX,” without the distinction. In fact, the only way to tell is by looking at the type and name of the endpoint on the shape. Because of this, I recommend a naming convention such as wsFoo and webFoo for Web Service and Web Application, respectively.

Similar to logical datacenter diagrams, the final step in creating application diagrams is to connect the shapes: applications to services and services to services. These communication pathways are similar to the lines you'd be drawing on your whiteboard, connecting your squares. As with logical datacenters, these lines convey a communication workflow to the casual observer, but they also document the connectivity requirements of your application. During the test deployment, the success or failure will depend on whether these shapes are still able to communicate with each other within a particular datacenter.

For example, if you design a Windows client and an ASP.NET Web service, connect them in the application diagram, and then try to deploy them onto two separate servers in two separate datacenter zones that don't allow HTTP communication, the validation will fail—as it should.

You'll learn more about the Application Designer in Chapter 5.

Deployment Designer

An architect can use the Deployment Designer to test a deployment of an application diagram against a logical datacenter diagram. As I've alluded to in the previous sections, the two diagrams have to mesh correctly—the settings of the application diagram applications and services have to mesh with the constraints of the logical datacenter diagram, and vice versa.

Once the two diagrams have been completed to the best of each architect's ability and insight, one of the architects, most likely the application architect, will define a test deployment and carry out the validation. Both diagrams will need to be in the same project at this point, and checked out of version control.

TIP
To define a test deployment, first open the application diagram and then right-click its designer, or choose the Define Deployment menu option from the diagram menu. At this point, you'll select a logical datacenter to deploy against. (See Figure 3-14.) Remember, a project can contain multiple datacenters, as a real company could have many sites and locations to deploy to.

Figure 3-14 Selecting a logical datacenter to test a deployment against

The Deployment Designer allows an architect to drag and drop the various applications and services, as defined in the application diagram, onto the various servers in the various Zones, as defined in the logical datacenter diagram. The applications and services can be found in the floating or dockable System View window. (See Figure 3-15.)

It really is that easy—drag and drop until all the shapes are bound. If your mouse pointer changes to the “no drop” shape, which is the familiar circle with a line through it, you're not allowed to drop that application or service onto that server.

Figure 3-15 The System View window, which lists all applications and services

TIP
If you happen to get the “no drop” mouse pointer, hover your cursor over that spot for a few seconds and a ToolTip will pop up explaining why you're not allowed to drop the item you're dragging. This is a nice feature.

At some point—either immediately after dropping a service or application or after you've finished all the drops—you should ensure that the correct bindings were used. For example, an IISWebServer can have several inbound or outbound endpoints. If you're lucky, the infrastructure architect named them well, making your job easier because when you bind your applications and services to the server, you need to choose the correct endpoint, as you might have different constraints on them. You can do this by right-clicking on the bound application or service within the logical server and selecting Binding Details. (See Figure 3-16.)

After all your applications and services are bound properly, your final step will be to validate the diagram. I say “final” assuming that all goes well and you didn't receive any warnings or errors. For large-scale, distributed applications deploying to large-scale, distributed environments, this might not be the case the first time you get to this point. You can find the Validate Diagram option on the Diagram menu. If any errors are detected, they'll be listed in the Errors List window, typically at the bottom center of the Visual Studio 2005 integrated development environment (IDE).

TIP
Reconciling validation errors might require the input and collaboration of both the infrastructure architect and application architect. If this happens to be the same person, it's fine. If, however, there are two people involved, I suggest using an eXtreme Programming engagement, in which you “pair program” the final fixes. In other words, both architects sit at the same keyboard and come up with the compromises together so that the application will deploy. Successful deployment could require loosening up the requirements of the application, the datacenter, or both.

Figure 3-16 The Binding Details window without good naming conventions

Once the validation succeeds, a deployment report can be generated that will serve as a bill of materials to deploy the application. We'll look at this report in more detail in Chapter 10. You'll learn more about the Deployment Designer in Chapter 5.

System Designer

The System Designer can be used to compose and configure pieces and parts of an application diagram into systems. A system is considered a unit of deployment and is a configuration of one or more applications and other subsystems. By combining complex applications into a system, you can more easily handle large-scale distributed system scenarios. An application architect can design a complex multi-tiered system as a hierarchy of “nested” systems.

Using System Designer, you can design application systems by composing them from applications or other systems. An application system describes a set of configurations, rules, and policies that apply to its members at deployment. These rules and policies include application settings that you might override as well as those governing connections between and access to members of the system. For example, you can design systems composed from applications that are configured for Internet and intranet use and then create, define, and validate deployment definitions for those systems.

TIP
If you want to connect a system with other applications or systems in other system definitions, you must add at least one proxy endpoint to the definition of that system. A proxy endpoint delegates communication with the system to the application endpoint from which the proxy endpoint is created.

Creating a system diagram allows for more granular deployment, defined independently of the entire configuration shown on the application diagram. In some cases, the settings defined on the application diagram as a whole can be overridden on the same application within a system diagram. In other words, multiple system definitions can be created, each having distinct configurations of the applications defined in the solution. This versatility allows different configurations to be defined for different deployments and perhaps for different logical datacenter configurations. Figure 3-17 shows how two existing ASP.NET Web services can be combined into a system, given a name, and then used directly in future deployment diagrams.

Figure 3-17 Combining two existing services into a system

TIP
Another way to gain some benefits of designing a reusable system is to simply add a server, service, or application to the toolbox for later use. (See Figure 3-18.) For example, if you know that your company has a standard Web server configuration (Windows Server 2003 Enterprise, Service Packs, .NET 2.0, and certain security configurations), design it once, describe it fully, and then right-click the shape and choose to add it to the toolbox, giving it a friendly name and optionally a graphic image. You can then drag and drop that item later and save yourself some configuration steps.

You'll learn more about the System Designer in Chapter 5.

Figure 3-18 Adding an ASP.NET Web service to the toolbox