Introduction to the Visual Studio 2005 System Designer
Summary: Learn how to use System Designer in Team Architect Edition to define how your applications interoperate as systems. (13 printed pages)
System Designer in the context of the Distributed System Designers
Setting up the Distributed System Solution
System Design Example
Settings and Constraints
Missing Application Definitions and Projects
Looking Ahead to System Deployment
In this article, I'll introduce you to System Designer, one of the four new Distributed System Designers provided by Visual Studio 2005 Team Architect Edition.
I'll start by explaining how System Designer fits together with the other visual designers as a coherent set. More specifically how using System Designer follows as the next logical step after using Application Designer, which I introduced in my previous article, and how it leads on to using Deployment Designer, which will be the subject of a future article.
I'll provide a practical demonstration of system design using the application design from my previous article as a starting point, but for your convenience I'll provide everything you need here so that you need not reread the previous article. Though, of course, reading my previous work is highly recommended.
My demonstration really will be a practical one because everything I describe here I have actually done using the Visual Studio 2005 Team Architect. And I'll invite you to do the same.
Following the example, I'll provide a preview of how systems will be evaluated for deployment once defined. I won't be digging deep there as it's the subject of a completely separate article, but it will help to complete the picture and give you a good idea of where you'll be heading next.
In the previous article I introduced you to Application Designer, one of the four new Distributed System Designers provided by Visual Studio 2005 Team Architect Edition. Once you've used that designer to devise the overall application architecture, the next logical step is to use System Designer to combine those applications into application systems.
As you can see in Figure 1, System Designer takes as input the application definitions that are created with Application Designer and produces as output a set of system definitions that will be evaluated for deployment using Deployment Designer.
Figure 1. Distributed System Designers
In this article, I'll show you how to use System Designer to design systems using application definitions.
Before you can start designing systems, you need a set of applications from which to compose those systems. I'll use the application set that I designed in my previous articles (Introduction to the Visual Studio 2005 Application Designer, Part 1 and Introduction to the Visual Studio 2005 Application Designer, Part 2) and whose definitions are stored in the application diagram file ApplicationDesign.ad, which I have provided again here for your convenience.
To get started, I create a new distributed system solution in Visual Studio 2005 by choosing the Distributed System template from the Distributed System Solutions project types when creating a new project. I name the solution SystemDesign, and remove the default application diagram (.ad) file, which is automatically included. Then I add in my precreated application diagram (ApplicationDesign.ad) by right-clicking the Solution Items folder in the solution, pointing to Add, and choosing Existing Item.
I invite you to do the same, in which case your starting point should look like Figure 2.
Figure 2. Visual Studio 2005 distributed system solution with an application diagram (ApplicationDesign.ad)
Adding an External Database
In my example that follows, I'll modify the application design slightly to incorporate an external database. That's because I'll be dividing the application design into two systems, and without the addition of a database, one of those systems will comprise only one application. Not that there's anything wrong with a system comprising only one application, and therefore you can treat the addition of a database as an optional step if you wish.
To add the database application, I drag the ExternalDatabase prototype from the Toolbox to the application diagram as shown in Figure 2. I rename the database to ExchangeRates, and connect it to the BureauDeChange application to produce the result shown in Figure 3.
Figure 3. Application design with an external database
If you try this yourself, you can create the connection by pressing the ALT key while clicking the ExchangeRates database endpoint and dragging to the BureauDeChange application. You'll find that when attempting to connect the ExchangeRates database to the BureauDeChange application, you are prompted to enter connection information for the database. Just cancel out of that dialog when it appears.
Now that I have a solution containing an application diagram—with or without a database—I can compose the applications into systems. A system describes a deployable configuration of applications. Systems are reusable and composable, and can be used to construct larger systems and complete user applications.
As the BureauDeChange application and the ExchangeRates database (if present) are potentially reusable in other contexts, I am going to compose these into a system that I will then use in my overall system. To create the system, I select these application definitions on the application diagram, then right-click and choose Design Application System. When prompted, I name this new system ExchangeRatesSystem and Visual Studio creates a new system diagram (ExchangeRatesSystem.sd) as shown in Figure 4.
Figure 4. System diagram (ExchangeRatesSystem.sd)
Note In this example, I have created a system diagram directly from the application diagram by pre-selecting the applications. Alternatively you can create a new blank system diagram as your starting point by choosing Add New Item or Add New Distributed System Diagram from the Project menu. If the solution does not contain an application diagram when you add a blank system diagram, Visual Studio adds a blank application diagram (.ad) file to the solution, and you can use this diagram to define the applications that you want to add.
In due course I'll be using that system within another system, and in order to do so I must first decide which endpoint(s) to expose as proxy endpoints at the system boundary. In the interests of proper encapsulation, I wouldn't want to expose the database endpoint at the system boundary, as all interactions with the database should be hidden behind the ExchangeRateService of the BureaDeChange application. So, I press the ALT key while clicking the ExchangeRateService endpoint and dragging it to the system boundary to yield the result shown in Figure 5.
Figure 5. ExchangeRatesSystem exposes ExchangeRateService
What I've done here is create a proxy endpoint that delegates (dotted line) to the application endpoint. Proxy endpoints identify and represent connection points that you can use to provide access to members of a system. A proxy endpoint always has the same type and role as the application endpoint to which it delegates. Therefore, a proxy endpoint created from a provider endpoint is also a provider endpoint, while a proxy endpoint created from a consumer endpoint is also a consumer endpoint.
I said at the outset that I would be defining two systems from my initial application design. The second system will comprise the remaining applications in my solution and reuse the ExchangeRatesSystem. To define this second system, I return to the application diagram (Figure 3), select the CurrencyConverter, DollarExchangeApp, and EuroExchangeApp applications all at the same time, right-click and then choose Define Application System. I name this system CurrencyConversionSystem.
Before I show you what the system looks like, I should introduce you to the System View window shown in Figure 6. This window appears whenever you view a system diagram and lists all the applications as well as other systems that are available to you when designing a new system. The subtlety there is that the System View window lists all the systems apart from the one you're currently designing, so as to avoid circular references. Therefore, the System View window in Figure 6 does not list the CurrencyConversionSystem itself. However, the System View window for the ExchangeRatesSystem system diagram would.
Figure 6. System View window for the CurrencyConversionSystem
If the System View window does not appear, you can make it appear by pointing to the View menu, then Other Windows, and choosing System View.
I didn't make use of the System View window when defining the ExchangeRatesSystem because I had already pre-selected all of the applications that were needed for the system. But if I had started with a new blank system diagram, I would have relied entirely on the System View window as the source for adding applications to the system definition.
In any case, I do need the System View window now so that I can drag the ExchangeRatesSystem to my new system diagram for the CurrencyConversionSystem and complement the three applications that I pre-selected.
Figure 7 shows the resulting system diagram in which I have also connected up the ExchangeRateService exposed by the ExchangeRateSystem to the CurrencyConverter application.
Figure 7. CurrencyConversionSystem with nested ExchangeRatesSystem
If you look back at the original application diagram in Figure 3, you might wonder why I had to once again connect up the ExchangeRateService to the CurrencyConverter client application. The answer to that is two-fold:
- The ExchangeRateService endpoint that I have exposed through the ExchangeRateSystem is not exactly the same endpoint as the one provided by the BureauDeChange application within the nested system. It is a proxy endpoint, and in fact I could have given this exposed endpoint a different name.
- It's one thing to define an endpoint on an application diagram in order to show what could be connected up in deployed systems. However, it's quite another thing to define what will be connected in those systems. I need not have made that connection at all at the system level even though it is available at the application level.
Now that I have completed the definitions of my two systems, I invite you to retrace my steps for yourself by defining an ExchangeRatesSystem and a CurrencyConversionSystem of your own.
Alternative System Designs
The above example demonstrates one way in which my applications may be packaged as deployable systems, but not the only way. Multiple system definitions may be created, each with distinct configurations of the applications defined in the solution—perhaps for different planned deployments, different datacenter configurations, or even for different customers. I might have test applications in my solution that I don't want to deploy or perhaps alternative implementations of the same application that I might use in different deployments.
Other ways that I could have chosen to compose my applications into systems include:
- A separate system for each individual application.
- One single system containing all applications.
- An overarching system containing the CurrencyConversionSystem and ExchangeRatesSystem, both at the same level.
Note that the last configuration in that list would not be quite the same as the arrangement in Figure 7 that had the ExchangeRatesSystem nested within the CurrencyConverterSystem.
I could even devise two systems—let's name them ExchangeRatesSystem2 and CurrencyConversionSystem2—that mirror their existing namesakes exactly. Exactly, that is, apart from the values of their settings that I discuss below.
Note The composition of applications into systems may be likened to the UML notion of mapping classes onto components for deployment. It's similar, but not the same because the applications themselves act as containers for individual classes whose capabilities are exposed through a limited set of interfaces, which in itself may also be likened to the UML notion of mapping classes onto components.
Now that I've given you some ideas, I hope I've whetted your appetite enough for you to experiment with the various system definitions that could be created from the initial application set.
As with Application Designer (my previous article), System Designer allows you to select a Web service provider endpoint and view the details of that service in the Web Service Details window. Notice that I said view, rather than view and edit because at the system level you are not allowed to modify the details of Web services.
Also as with Application Designer, System Designer allows you to view settings and constraints information for an application or endpoint. I created Figure 8 by selecting the CurrencyConverter application on the CurrencyConversionSystem diagram (Figure 7), and viewing the Settings and Constraints editor. I selected that application so that if you read my previous article, you'll now be experiencing some deja vu. Although this figure is pretty much identical to one of the figures in the Application Designer article, you can rest assured that this time I have gone the system diagram route rather than the application diagram route.
Figure 8. Constraints for CurrencyConverter application
In Figure 8, I have highlighted the logical server constraints, which describe requirements of the hosting environment. These constraints are fundamental to the definition of an application and so are not modifiable per use in a system.
Figure 9 shows a subset of the settings that I would see if I selected the DollarExchangeApp in System Designer while viewing the Settings and Constraints window. As you can see, the specific setting that I have chosen to override in Figure 9 is the AuthExpiredUrl setting, which is highlighted.
Figure 9. AuthExpiredUrl setting for DollarExchangeApp in System Designer
That setting would be relevant if I decided to limit access to the DollarExchangeApp through authentication, in which case I could specify a URL for the user to be redirected to in the case that the authentication had expired.
Actually, I won't be securing that application through authentication as it's beyond the scope of this article, but it does illustrate the essential point that I can override that setting in System Designer only because the setting was marked as overrideable in Application Designer. You can see what I mean by looking at Figure 10, which shows the same setting when the same application is selected in Application Designer rather than System Designer.
Figure 10. AuthExpiredUrl setting for DollarExchangeApp in Application Designer
As you experiment with System Designer, you may at some point encounter the problem of an application being shown with a dashed red outline on a system diagram. This indicates that the definition of the application, required by the system, is missing. The most likely causes for you to check are:
- The application has been removed from the application diagram.
- The project for the application is unloaded or not part of the solution.
- The application definition on the application diagram was renamed while the system diagram was closed, thus the two diagrams could not be synchronized.
Having created one or more systems, the next logical step would be for me to evaluate deployment for those systems, which requires a logical datacenter diagram. A logical datacenter diagram is a logical representation of a target datacenter, while a deployment diagram describes how applications are to deploy in that datacenter.
I won't be showing you how to use logical datacenter diagrams and deployment diagrams, and I won't be asking you to draw any because they are covered in depth in two future articles. However, I would like to show you what the end result might be if I evaluated deployment for the CurrencyConversionSystem using a suitable logical datacenter diagram.
Figure 11 shows a deployment diagram that includes the System View window from which I have dragged applications to three logical servers—CurrencyWebServer (IISWebServer), ExchangeServices (IISWebServer), and ExchangeRatesDataServer (DatabaseServer).
Figure 11. Deployment diagram for CurrencyConversionSystem
When I drag an application to a logical server, providing that server is suitable for hosting the application, then the application becomes bound to that server. Therefore, the deployment diagram describes the following bindings:
- The CurrencyConverter Web services application, plus the DollarExchangeApp and EuroExchangeApp front-end Web applications are bound to the CurrencyWebServer; to be served up to the general public through the Internet or the company outlets through the intranet.
- The BureauDeChange Web services application is bound to the ExchangeServices server, and the ExchangeRates database application is bound to the ExchangeRatesDataServer.
Notice that the ExchangeServices and ExchangeRateDataServer are contained within a zone, a protected region of the network, named ExchangeZone. This mirrors the fact that the BureaDeChange and ExchangeRates (database) applications are defined within a separate subsystem. Remember that in my Application Designer article I suggested the BureaDeChange as a candidate for a third-party-supplied service. Because the only connection into the ExchangeServices server is through the zone boundary, there is no possibility of accessing the underlying database through any other route.
I'm sure you get the picture now and I don't want to steal someone else's thunder, so my preview of evaluating system deployment will end there. Hopefully it's piqued your curiosity for more about logical datacenter diagrams and deployment diagrams, and as you read those articles, it will hopefully help to put the discussion into the context of the systems that I have defined here.
In this article I have introduced you to System Designer, which forms the vital link between applications (my previous article) and deployment evaluation (covered in depth in an upcoming article).
Applications are configured into systems for deployment, and in my working example I demonstrated how the composition of applications into systems is achieved in practice. I discussed how settings defined at the application level can be overridden at the system level, so as to provide alternative deployment possibilities.
Now that I've taken you through application design and system design, Mickey Williams will follow the separate track (see Figure 1) with Logical Datacenter Designer and Deployment Designer, thereby pulling the whole thing together.Tony Loton is an MCP who wears various hats as Principal Consultant / Director of LOTONtech Limited (www.lotontech.com), as Principal Consultant / Head of Microsoft Practice at Cogenture (www.cogenture.com), and as Associate Lecturer with the UK's Open University. He is currently co-authoring the book Professional Visual Studio 2005 Team System (ISBN 0764584367) to be published by Wiley / Wrox in summer 2005.