Visual Studio 2005

Bridge the Gap Between Development and Operations with Whitehorse

Brian A. Randell and Rockford Lhotka

This article is based on a prerelease version of Visual Studio 2005. All information contained herein is subject to change.

Contents

Application Design
Deployment Cycle
The Class Designer
Conclusion

Whenever you want to use a modeling tool to describe software systems, you're frequently faced with a serious investment of time and money. Often the diagrams that result look great, but are quickly forgotten as development gets into full swing. While there are tools on the market that provide for synchronization between diagrams and code, their cost and the time required to learn them has put off many if not most users (unless their full-time job is to produce such diagrams).

An additional problem has been the mismatch between the design of the system and the characteristics of the environment into which it will be deployed. Many times a solution looks great in a diagram, gets coded, and then when deployment time comes, there's a rush to solve problems that emerge because the model does not map correctly. The competing priorities of architects, designers, developers, and infrastructure personnel can lead to conflict. Often there are conflicting constraints that must be reconciled in the beginning. These constraints, such as physical server security, become obstacles to the successful deployment and implementation of new systems. Added to the mix is the increasing complexity of today's environments which have evolved from central mainframe-only systems to the client/server model, and on to distributed systems.

Today, one very popular environment is the service-oriented architecture (SOA), which is built from loosely coupled, autonomous applications that offer services, communicate using messages, and often cross trust boundaries. Right now XML-based Web services built with ASP.NET provide a platform on which to build these kinds of systems. As technologies evolve, Microsoft will be shipping a variety of technologies to make it easier for you to build and manage these systems and to extend the capabilities of the underlying platform.

In the time frame of Visual Studio® 2005, Microsoft is introducing a new suite of graphical design tools, code-named "Whitehorse," to make it easier to design and implement systems using SOA. These include the new Class Designer as well as a group of four tightly integrated tools referred to as the Distributed System Designers. One of these four, the Application Connection Designer, and the Class Designer share a key characteristic. Both support the graphical design of systems and components and include support for code generation. What's more, the designers support bidirectional synchronization so you no longer have to be concerned that a diagram doesn't represent the system and its components. Whitehorse represents a renaissance in modeling in that it goes beyond the typical documentation-centric view of modeling systems. The designers are tightly integrated into the Visual Studio shell and each diagram is a first-class artifact in a solution, just like other program sources. This subjects the diagrams to source code control to support team scenarios.

The new Logical Datacenter Designer tool allows operations architects to provide a description of the types of servers in the target environment and record the configurations of the host software packages loaded on those servers. With this detailed knowledge of the target environment, and detailed information about the logical software model, Whitehorse allows the software developer to bind services to servers and provide a validation process to make sure that the design will actually deploy successfully in the datacenter. Otherwise, it will highlight the need to make changes in the datacenter configuration itself. In this way, organizations can avoid costly downstream deployment problems and can apply fixes early in the development process.

This ability to design a service-oriented system and immediately validate it against the operations infrastructure is called Design for Operations. Applications are often designed in one environment but are meant to be deployed in another or even multiple environments. With Whitehorse, the ability to validate a design against a model of a target datacenter makes deployment smoother. Whitehorse is a key part of the new Microsoft® Dynamic Systems Initiative (DSI), a long-term industry initiative to simplify and automate the development, deployment, and operation of connected systems. With it the operations team can map their view of the world to the architect's view. Constraints can be enforced in both worlds, forcing communication through the validation mechanism from the start of the project to help ensure successful system deployments.

The best way to understand the tools is to walk through building a simple system using the Distributed System Designers.

Application Design

The Whitehorse tools introduce a new Distributed System solution type. When you create a new solution, the first designer you'll encounter is the Application Connection Designer. This designer provides a design surface for defining Web service applications and their client Web or Windows-based applications. These applications can be created directly on the design surface or, if an Application Connection Diagram is added to an existing solution, it will analyze the solution to create the diagram. The designer enables you to connect applications, defining the communication pathways that must be supported in the code. It also enables you to experiment freely with the application settings and design before generating the skeleton implementations for developers to implement. Basically, it supports "whiteboarding" your design before committing to code, thus allowing you to explore and experiment with your system design.

The Visual Studio Toolbox provides a set of components that represent Windows-based applications, Web services, and databases (see Figure 1). Using drag and drop, it's easy to lay out a system. For example, to specify that a database connection is required, you drag and drop an ExternalDatabase component onto the design surface. Then using the standard Properties windows in Visual Studio, you set the connection string for the database. With your data source defined, the next step is to add a data access layer in the form of a Web service. After dragging a Web service onto the design service, it can be bound to the previously defined data source by dragging a connection between the two.

Figure 1** Toolbox **

The next step is to expose the data via a Web service interface. To do this, you click the Web service's endpoint, created by default, and using the Endpoint Details window, define the public entry points. To generate the application skeleton, right-clicking on the Web service provides an Implement command. Running this command adds a new Web service project to the solution, configures the local instance of IIS, and generates a set of language-specific source and configuration files. Opening the Code folder in the Solution Explorer exposes two class files, one for the implementation of the Web service, the other a useful utility class for retrieving the database connection string generated into the web.config file. Filling the stubs of the Web service class with some standard data access code completes the process. At this point, if a correction or adjustment was made to the public entry points in code, these changes would automatically be synchronized with the system diagram.

Testing the initial design works just as it did in earlier versions of Visual Studio, so you simply press F5 and it runs. Assuming that everything works fine, it's now time to add a front end to the Web service. Back in the Application Connection Designer, drag and drop an ASP.NET Web Application onto the designer surface. Just like before, you need to bind the components together. This is done by clicking the exposed endpoint of the Web service and dragging a connection link between the Web service and the Web Application. Next, right-click over the Web Application and select Implement. Visual Studio will then add a new Web Application project to the solution and create a Web reference to the Web service. You then add a default Web page just as in previous versions by using the Add New Item command.

Figure 2** App in Distributed Solution **

Using the Web Forms designer, we add an ObjectDataSource component to link the Web service to our UI, which is a GridView control on the Web page. The ObjectDataSource takes care of invoking the exposed methods from the Web service. In this example, we don't have to write any code. We have to make just a few adjustments to the GridView control's properties and then press F5 to show data from our Web service in the Web browser. Figure 2 shows the completed application in the Application Connection Designer.

Deployment Cycle

The next phase requires that a logical model of the network and actual server types in a deployment environment be defined. This step could have already been completed by the operations team. For this example we'll use the Logical Datacenter Designer, which is used to create diagrams that represent a logical model of the application hosting capabilities of a datacenter. The designer allows the infrastructure architect to specify the datacenter topology by presenting system entities like database servers, Web servers, logical security zones, and communication endpoints. In addition, constraints can be applied against the application configuration based upon the needs of the datacenter.

Figure 3** Types **

In the existing solution, we'll add a new Logical Datacenter Diagram. Just like before, we'll use elements, exposed on the Toolbox, specific to this designer. Figure 3 shows a list of the current logical server and endpoint types supported. We'll add two zones to the diagram. The first represents the demilitarized zone (DMZ), and the second represents a secure inner zone of the network. Next, we'll define a hardened IIS Web server in the DMZ. In the inner zone, we'll add an IIS Web server called "AppServer," and a machine running SQL Server™. In the case of the IIS Web servers, predefined input and output endpoints exist. Using the Connection tool, we connect the various input and output channels, including the connection between the AppServer and the SQL Server machine. Figure 4 shows the completed logical datacenter diagram.

Figure 4** Completed Logical System Architecture **

With the diagram defined, we can now add constraints to the logical servers. For example, we could require that the AppServer use impersonation and SSL. We simply select the AppServer and open the Settings and Constraints editor as shown in Figure 5.

Figure 5** Settings and Contraints Editor **

There are several types of constraints supported in Whitehorse: Constraint dialogs, user-defined constraints, and implicit (or built-in) constraints. The Constraint dialogs (shown in Figure 5) logically group together settings of a particular type, for example ASP.NET membership or Web site Configuration. These dialogs have editing rules built into them to allow specific combinations of settings to define the constraint. User-defined constraints allow a user to have full control over desired values and ranges for any setting available on the logical server or application. Implicit constraints are supplied in the model and are applied without the user having to perform an explicit action (other than validate). For example, if the .soap and .asmx script maps were removed from IIS, the Web server wouldn't be able to support Web services. Note that settings may also be imported from existing servers such that an accurate model of the Web server in the actual deployment environment is used for constraint evaluation.

The last step in the process is to map the applications we defined earlier to our newly defined logical system architecture. We can either make an assumption that the configuration used in the development environment is the configuration needed for deployment and define what is referred to as a Trial Deployment, or we can explicitly create a new system in which we can configure settings that are specific to the deployment we are planning. In most cases, people will start with a Trial Deployment to weed out the most serious issues and then create a system as the final step to locking down the configuration. Systems can be composed into more complex definitions, allowing reuse in the design of large-scale architectures.

We are going to create a Trial Deployment. We select Define Trial Deployment from the Application Connection Diagram and then, in a pop-up dialog, select the Logical Datacenter design we created earlier. The Deployment Designer is opened with a new deployment diagram depicting the logical datacenter as a backdrop. The Deployment Designer then allows us to bind each application to a logical server, indicating the type of server to which it will be deployed. This is done by dragging and dropping the application either from a simple outline control or directly from the Application Connection Diagram. If the server is incompatible with the application to which we're trying to bind, the no-drop symbol is displayed. The process is repeated with each application, creating a virtual deployment of the system. Once we've mapped all of our components to the appropriate hosts, we can validate our mapping, as shown in Figure 6.

Figure 6** Subsystem Mapper **

Validation checks all of the bindings, confirming the constraints defined in both diagrams and verifying that there are communication pathways in a logical datacenter that support the pathways and protocols required by the application. If there are any errors, a task item is added to the Visual Studio task list. Double-clicking on the items in the error list takes us to the offending diagram and component. In this example, we set a constraint in the Logical Datacenter Designer to require our AppServer to use ASP.NET Impersonation. When we ran validation, we got an error. By double-clicking on the task, we're taken to the Application Connection Designer with the invalid endpoint selected. After adjusting the correct property in the Settings editor, the value is automatically written to the web.config file, we revalidate, and everything is done. The advantage here is that we find deployment problems before we deploy (possibly even before core development has started), not during the actual stress-filled hours before going live.

At this point, the design can be handed off to developers who can start working with the Class Designer in order to map out the heart and soul of the system.

The Class Designer

Most object-oriented developers like to create diagrams of their application designs and often these take the form of Unified Modeling Language (UML) documents. UML defines several types of diagrams you can use to model your application. The most commonly used diagram type is the class diagram, which shows each class in your application, along with their relationships to other classes. Typically, each class is displayed in a box with its fields and methods listed.

Unfortunately, UML has fallen behind current technologies such as the .NET Framework. For instance, there is no provision in UML for the Friend and internal scope in Visual Basic® .NET and C#. Nor is there any elegant way to list property methods or events, which are key parts of the interface for .NET classes.

It is difficult to keep code and diagrams in sync. Some UML diagramming tools allow code generation from a diagram and diagram generation from code, but there are limitations. Therefore, most developers avoid the use of code generation, which means they must manually keep the diagrams and code in sync over time.

To help address these problems, Microsoft is developing a Class Designer tool which is scheduled to ship as part of Visual Studio 2005. The Class Designer produces diagrams similar to a UML class diagram, with the addition of features to support all the design concepts available to programmers using .NET. Additionally, the Class Designer is fully integrated into Visual Studio 2005, so the diagrams it creates are part of your project along with your code.

The integration with Visual Studio 2005 is not only convenient, it means that the Class Designer can do real-time code generation and generating diagrams from code. Put simply, the diagram is instantly updated as you change the code, and your code is instantly updated as you change the diagram.

Figure 7 shows the Class Diagram tool in Visual Studio 2005, along with the matching code that was generated for the diagram. Changing either the diagram or the code is fine. Both remain in sync automatically.

Figure 7 Basic Class Diagram

Using the Class Designer requires that you add a Class Diagram to your project in Visual Studio 2005. You do this by adding a new item to the project and choosing the Class Diagram template.

If you already have classes in the project, they can be added to the diagram by dragging them from the Class View window onto the diagram's designer surface. This will cause the Class Designer to add the class to the diagram, and list all the methods, fields, properties, and events in the class. An example of such a class is shown in Figure 8. Note that not only are the details of the class shown in the diagram itself, but when the class is selected in the diagram, the details also appear in the Class Details window at the bottom of the display.

Figure 8** Dragging a Class from Class View to Class Diagram **

Using the Class Details window you can view and change the interface of the class. This includes adding and removing methods, fields, properties, and events. You can also change the scope, parameters, and return types of these elements. Any change made in the Class Details window is immediately applied to the code.

Notice the Summary column in the Class Details window. This column displays the summary information about the interface element from the XML documentation in the code. You can also change the XML documentation in the code by editing this column. Better still, when you select this column, a button is available to bring up a dialog where you can edit more of the XML documentation.

The resulting Visual Basic .NET comments are automatically added to the code, as shown in the following code snippet.

''' <summary> ''' Returns the ID value of the product. ''' </summary> Public ReadOnly Property ID() As Guid Get Return mID End Get End Property

The same is true for C#, C++, or J# code (though there are some restrictions for C++). Changes to the diagram are immediately reflected in the code of your project; likewise, changes to your code are reflected in the diagram. Suppose, for example, you start with the C# code in Figure 9. Dragging this class from the Class View to the Class Diagram produces the illustration shown in Figure 10.

Figure 9 A Simple C# Class

using System; namespace Sales { public class Customer { string _name = string.Empty; public string Name { get { return _name; } set { _name = value; } } } }

Figure 10** MTS **

Not only can you drag and drop your classes, but you can drag and drop classes from other assemblies referenced by your assembly. When you do this, the external classes are shown in the diagram in a read-only mode since they aren't directly part of the current assembly. This allows you to provide a more comprehensive diagram that illustrates the relationships between your classes and the classes from referenced assemblies.

You will also be able to drag and drop an entire project from Solution Explorer onto the diagram if you want all the items in the assembly displayed in the diagram. Initially there won't be any auto-formatting provided for the newly added elements in the diagram, but hopefully that feature will be added prior to the release of the tool.

To illustrate how the diagram is updated when the code changes, you can add the following property to the class:

int _id; public int ID { get { return _id; } set { _id = value; } }

The diagram is immediately updated to display the newly added ID property and field.

It is also possible to start with the diagram, rather than with code. When the Class Diagram Designer is open, you can drag and drop elements from the Toolbox onto the diagram. This automatically creates the associated code file and adds the item to the diagram. Using the Toolbox, you can add most common coding constructs, including classes (both abstract and concrete), enumerations, interfaces, structures, delegate definitions, and Visual Basic .NET modules.

You can also use the Toolbox to add inheritance and association relationships between elements on the diagram. These relationships are immediately reflected in the code. For instance, if you click the Association tool, then click and drag from a Product class to an InventoryQOH class, the following code is generated in the Product class file:

Public Property InventoryQOH() As Inventory.InventoryQOH Get End Get Set(ByVal Value As Inventory.InventoryQOH) End Set End Property

This new InventoryQOH property does not appear as a property in the Product class because it is displayed graphically as an association line between the Product and InventoryQOH classes in the diagram. Likewise, if you add an Inheritance relationship between two classes, the appropriate inheritance relationship is added to the code.

From the Toolbox you can also add arbitrary comments to the diagram itself. These comments are only part of the diagram and have no impact on the code in the project. These are different from the XML documentation associated with each code element in the diagram, which are part of both the diagram and the code.

The Class Diagram file in a project has a .cd file extension. It is a simple XML file that contains details about each element in the diagram. Since most of the data in the diagram flows directly from your code, there is not a lot of information stored in the XML file itself. For instance, the Product class shown earlier has the XML shown in Figure 11.

Figure 11 XML File for the Class Diagram

<Class> <AbsoluteBounds X="0.5" Y="0.5" Height="1.794798172314962" Width="1.5" /> <ShowAsAssociation> <Property Name="InventoryQOH" /> </ShowAsAssociation> <TypeIdentifier> <FullName>Inventory.Product</FullName> <FileName> C:\Documents and Settings\Administrator\My Documents\Visual Studio\Projects\Inventory\Inventory\Product.vb</FileName> <SiblingOrder>1</SiblingOrder> <HashCode>AAAAEAAAAAAAgAAAAIAAAAQAAAAAAAAAAAgAAAAAAAA=</HashCode> </TypeIdentifier> </Class>

The core of the element is the <TypeIdentifier> element, which contains the name of the class and a pointer to the actual class file. This allows the designer to read the class file to derive most of the details about the class itself. The <AbsoluteBounds> element indicates the position of the item in the diagram.

There is also a <ShowAsAssociation> element. This exists because our diagram, shown in Figure 7, has an association between Product and InventoryQOH. Because this relationship is reflected in the diagram, the XML includes a reference to the specific property in the Product class that creates the association.

If we return to the Class Diagram, we can right-click the association line and choose the Show as Property option. When you select this option, the association line between the Product and InventoryQOH classes is removed from the diagram, and the InventoryQOH property is displayed as a property within the Product class itself. To reverse the process, you can right-click on the InventoryQOH property in the Product class and choose the "Show as Association" menu option.

By turning off the "Show as Association" option, we have changed the diagram, but not the code. In other words, the association between Product and InventoryQOH is unchanged and only the display is affected. This is reflected in the XML for the diagram because the <ShowAsAssociation> element has been removed from the Product entry in the XML.

Conclusion

The Class Designer should be a very nice tool for object-oriented designers and developers using Visual Studio 2005. It provides a UML-like class diagram that is capable of reflecting all the language features of Visual Basic .NET and C# in the Microsoft .NET environment. Not only does it allow you to create accurate diagrams, but it keeps the diagram and code in sync in real time. You can now look forward to a time when your class diagrams truly reflect your code. The ability to move from diagram to code and back will ensure that your pretty pictures are more than just a memory of something that could have been but, in fact, are accurate maps of your functioning system.

Brian A. Randell is a senior consultant with MCW Technologies, a Microsoft Certified Partner specializing in custom application development with .NET, SQL Server, and the Microsoft Office family of products. Contact him at https://www.mcwtech.com.

Rockford Lhotka is the author of Expert One-on-One Visual Basic .NET and C# Business Objects (APress) and is a columnist for MSDN online. He is the Principal Technology Evangelist for Magenic Technologies, a Microsoft Gold Certified Partner.