The .NET Platform
Development Tools
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
We found this book useful!
You are not logged in: login here to access all areas.
Visual Studio Team Edition for Software Architects
The Architects edition of VSTS is based around a completely new workflow that takes you from architecture to deployment through three new design tools. Ian Murphy investigates. (Copy now revised for Beta 2!)
Author: Ian Murphy
Last updated: May 2005
NOTE: This article is based on Beta 2 of the software, so the features described may differ from those of the final release. When Microsoft purchased Visio, there was a lot of discussion as to how the company would develop the product. Although Visio does come with diagramming libraries that support the main methodologies, it wasn't intended to become a software modelling tool. Indeed many saw Visio as part of Microsoft Office. The workflow With the Architects edition, Microsoft has built a logical workflow that it believes will improve solution design and deployment. You start with the Application Designer which is used to build Application Diagrams. These show how the individual applications that will make up your solution link together. They can be Web applications, Web services, Windows applications, Office applications, or external databases or Web services. Defining the application The Application Designer window is simply a canvas on which to paint your solution. The toolbox contains a wide range of applications prototypes that you might want to include, such as ASP.NETWebApplication, ASP.NETWebService, WindowsApplication, OfficeApplication and ExternalWebService. There are others and more will be added in the final product. As with the templates, you can search MSDN for new definitions and derive your own from existing prototypes. This is where you can specify the type of server required for a particular application, and how it needs to be configured. Each application will usually be implemented as a single Visual Studio project. Right-clicking an application gives you the option to implement either that particular application or all the applications within the diagram. This creates the skeleton which becomes the starting point for writing the code. Once the skeleton is generated then both the diagram and the code will be kept synchronised. Class Designer Logical Datacenter Designer The Servers listed in the Toolbox are IISWebServer, DatabaseServer, WindowsClient and GenericServer. You can extend these, so if for example you configure a hardened IIS server configuration specifically for eCommerce, you might want to import the settings and save it as a new prototype for later reuse. Over time, Microsoft should add more server prototypes and it would be odd if they didn’t create prototypes for all their main server applications. Deployment Designer
That hasn't deterred Microsoft from pushing Visio as part of their architect solution package. However, with Visual Studio Team Edition for Software Architects, Microsoft has at last introduced a real architect solution. Beneath the generic heading of Distributed System Designers (DSDs) are a powerful range of design tools, many of which come from a project formerly known as ‘Whitehorse’ (see our interview with Keith Short for further details). This is much more than a traditional application designer.
This doesn’t mean that Visio has gone away. With Beta 2, it comes as a separate install and you can either use it as a standalone product or invoke it from the integrated development environment (IDE). This will allow you to import an existing project into Visio and generate UML diagrams. Oddly enough, Microsoft still insists on not including the help files with the Visual Studio installation.
With the Architects edition of VSTS, Microsoft has acknowledged that the complexity of distributed software requires more from tools than simply code modelling. There is a need to map applications to the physical environment in which they will run. Microsoft therefore divides the DSDs into one set for use by application architects and developers for designing the systems, and another for use by infrastructure architects for modelling the virtual datacenter. The point at which they meet is the Deployment Designer.
Before getting started with the DSDs you should take time to understand the System Definition Model (SDM). The SDM not only provides the underlying metamodel for DSDs, it also provides a common language. Perhaps one of the biggest advantages of the SDM is that it is extensible, allowing you to define information about your application that other layers of the model can use.
One thing to be aware of here is languages. If you have installed all the languages, the default for the DSDs is Visual Basic. If Visual Basic is not installed then the default becomes C#. If you want to ensure that specific DSDs start with a given language then you will need to make an Application Prototype and add it to the Toolbox. This is a simple two-click operation.
The Application Diagram is used to create an Application Definition which becomes the input to the System Designer. Here you define the System Diagram and the System View. The term 'system' is used here mean an application or group of applications that form a deployable unit, so this naturally leads to the Deployment Designer.
The Deployment Designer is where both groups of architects come together. While the system design is being done, infrastructure architects will be busy in the Logical Datacenter Designer creating the Logical Datacenter Diagram. Definitions generated here also feed the Deployment Designer where they are matched with the System View to produce a Deployment Diagram. It all seems remarkably simple on the surface but there is a lot being done under the covers.
Microsoft is effectively merging two key knowledge domains here: the application knowledge from the architects and developers domain, and the data centre knowledge from the operations managers or infrastructure architects domain. This is a new departure for the development process and begins to resolve some real issues that have led to massive problems with application performance and security over the last few years.
The logical data centre is a model of the actual servers that make up your data centre, and would typically be built by the operations department. Their tool of choice is usually something like Visio as they are not actually producing code. However there is no import from Visio, and Visio is not capable of capturing all the information that is needed. Until someone produces a Team Foundation Server client specifically for the operations department, they’ll need to use the full Architects edition to build their model.
For this to work the Logical Datacenter Model has to capture information about what is installed on each server and how it is configured. Without that information the Deployment Designer can’t generate a Deployment Document that will ensure a reliable installation. Much of that data should be held inside products such as Microsoft Operations Manager (MOM) and this is where we see how this plays into Microsoft’s Dynamic Systems Initiative (DSI).
The really clever thing here is that you have a coherent architectural viewpoint from conception right through to deployment. This is a seriously clever idea that should give us better security and more robust installations. Security is enhanced through the ability to designate servers to security zones. Robustness improves because you can ensure that the components you need are on the server before installing the application; if they are not, you can create a configuration guide.
Creating the application definitions is straightforward. You start by creating a new project of type Distributed Systems Solutions. Beta 2 offers you two installed templates: Distributed System and Logical Datacenter. You can create your own templates or, if you have configured the help system to search online resources, you can look for other templates. Choose Distributed System, and once you have named and saved your project the IDE opens with the Solution Explorer populated and the Application Designer window visible.
Here we have used the Application Designer to define two Windows clients and a Web client that talk to the Catalog through two Web services. The Catalog in turn is linked to an external database.
All you do is select and name a prototype and then connect it to others through their endpoints. Different types of application support different types of prototype, but there is a clear visual indication when you get it right, and a complete list in the Beta 2 documentation. This rich imagery and ease of use should help to visualise systems at an enterprise level, and companies may want to build DSDs to help them get to grips with their existing projects.
Right-clicking on an endpoint for an ASP.NETWebService application, for example, allows you to define the operations and parameters for the particular Web service that it represents. Alternatively you can import the definition from an existing WSDL (Web Service Description Language) file. You can also define Settings and Constraints specifying, for example, the type of server that the application can run on, and what settings it requires. This information is stored in the metadata for the application.
At this point you need to check the language in which the application will be implemented. You can still go to properties and change it to Visual Basic, C# or J#, but once you generate the skeleton you can’t go back. You are presented with a warning screen that tells you that you cannot reverse the process, and if unsure, make a copy of the solution before implementing it.
Built in to each of the Visual Studio Team Editions, but not one of the DSDs, is the Class Designer. Microsoft is being very careful how it positions the Class Designer. As it stands Microsoft accepts it needs to look at a number of things such as support for multiplicity, the ability to edit the data type on the design surface and the lack of support for the Using statement to connect child and parent classes. There is also no support yet for linking class and database diagrams. However there are a lot of well established tools out there and there is hope that third parties will step up to fill this space.
As a result Class Designer is being positioned more as a code visualization tool than a conceptual modeller, and its main purpose here is to support the Application Designer. Application definitions created in the Application Designer can become the projects where your classes are stored, while classes created in the Class Designer may contribute to the definition of services provided by applications defined in the Application Designer. Diagrams created in the Class Designer are simply views onto the underlying code. Add a new class and the appropriate code is immediately added to your project, and both code and diagrams are kept synchronised at all times.
Defining the systems
Once you have defined your applications and validated the connections you can begin using the System Designer to define the systems that will make up your solution. The starting point is the Application Designer where you select the applications that you want to be part of your new System. Simply multi-select the applications, right-click and choose Design Application System. This opens the System Designer with the selected applications in place.
If this system is just a subset of your overall application then you will have unconnected endpoints. You need to create proxy endpoints to allow them to connect to external systems, which you do simply by right-clicking the endpoint and selecting Add Proxy Endpoint.
Once you have created a System it becomes just another component in the System View, which already lists the applications you defined earlier. You can create as many systems as you like from your original Application definition, and any of the Systems listed can be used as components in new Systems.
The advantage of this approach is that each system becomes a separate component in your solution. You could, for example, split out thick client, smart client, web client, mobile client and backend systems, and give each to a separate team for development.
While this is going on, the infrastructure architect will be building a Logical Datacenter using the Logical Datacenter Designer. This is a virtual copy of the datacenter where the systems are to be deployed. You open Logical Datacenter Designer by creating a new Distributed System Solutions project, but instead of created a Distributed Solution you select Logical Datacenter. You are then presented with a blank canvas on which to paint your datacenter.
An important concept here is that of zones. These might be communication boundaries, physical boundaries where servers are located at different sites, or they might represent security constraints such as DMZ or internal servers. Once you’ve added the appropriate zones to the diagram, you can start placing your servers within them. You can speed up the process by importing settings from existing servers within your datacenter. At the moment this only works with Internet Information Services (IIS), but Microsoft is promising to extend support to other types of servers at some point in the future.
The Logical Datacenter Designer is used to model the datacenter where your solution is to be deployed. Note the zones which define different areas in the datacenter. The Intranet zone, for example, would have different security settings to the SecureData zone.
There must be close co-ordination with the operations manager to ensure the diagram is accurate. If a server is placed in the wrong zone then it will receive the wrong policies and constraints. As a result, an application could become unusable due to unexpected restrictions imposed on it by the server on which it has been deployed. Conversely, the solution may deploy with applications exposed to the outside world when they should be sitting inside a secure firewall.
Once you have finished the Logical Datacenter diagram you can deploy your solution against it. This is where the effort put into creating the Logical Datacenter diagram pays off. You start by right-clicking the system that you want to deploy and selecting Define Deployment. This opens up a dialog box from which you select the appropriate logical datacenter.
The Deployment Designer then opens with the logical datacenter you have chosen displayed. You also get a System View showing all the systems and applications that you have created. Now all you have to do is drag and drop the applications over the servers where you want them deployed. If the application can be hosted on that server then you will be allowed to drop it. If not, then there is a mismatch between the requirements of the application and the settings and constraints of the server which you or the operations department will need to fix.
One of the key goals of the Deployment Designer is to build scripts that will allow applications to be deployed automatically. This is done through the Bill of Material (BoM) report which utilises all of the metadata created inside the Deployment Designer.
The BoM report is not an installation script but an XML document that does contain the elements needed to build an MSI file. Inside the BoM are version details of all software on the servers in the deployment diagram, and their patch level. Changing a patch level can cause problems with installs, but as there is detailed information here, the installer can write exception routines to warn operators that the script was designed for a different patch level. Just this one feature should improve the consistency of installations by providing a benchmark against which working and failed installs can be compared.
Click here for our Privacy Statement. Copyright © Matt Publishing. All rights reserved. No part of this site may be reproduced without the prior consent of the copyright holder.
Introducing Visual Studio Team System Visual Studio Edition for Software Developers
