Introduction to the Visual Studio 2005 Application Designer, Part 1
Summary: Get a practical introduction to Application Designer, starting with the design of a service-oriented system. (8 printed pages)
In this article I'll introduce you to Application Designer, one of the four new Distributed System Designers provided by Visual Studio 2005 Team Architect Edition.
I'll start by explaining how Application Designer fits together with the other visual designers as a coherent set. Then I'll provide a practical demonstration of application design using a currency conversion service-oriented example that I have devised. And when I say practical, I mean that I'll show you how I really did design that distributed system using Visual Studio 2005 Team Architect.
In Part 2 of this series, I'll discuss implementation of the service-oriented example I designed in this initial article. I'll wrap up by discussing how some of the other application types—namely external Web services and external databases—can be incorporated into an overall design.
The Visual Studio 2005 Team Architect edition provides four visual designers collectively known as the Distributed System Designers. As you can see in Figure 1, these designers act together, and it is important to review the relationships between the complete set before digging deep into any one.
Figure 1. Distributed System Designers
Application Designer allows you to define the applications that comprise a distributed system. You can then use those application definitions in System Designer to compose applications into deployable systems. Following this, you can evaluate system deployment using Deployment Designer.
Independently, Logical Datacenter Designer allows you to define a logical representation of the target datacenter in which applications (composed into systems) will be deployed. Consequently, Deployment Designer takes as input not only a set of system definitions from System Designer, but also a set of logical server definitions from Logical Datacenter Designer.
This article series describes every one of the Distributed System Designers shown in the illustration. The article you are reading now focuses on Application Designer.
Before you can start designing distributed systems using Application Designer, you must either create a distributed system solution in Visual Studio or add an application diagram to an existing solution. Creating a distributed system solution is easy. You simply choose the Distributed System template from the Distributed System Solutions project types when creating your new project.
Initially, your new solution contains an application diagram with an .ad extension and the same name as the solution. If you name the solution ApplicationDesign, as I did, the application diagram will be named ApplicationDesign.ad. You can have only one application diagram in your solution because it describes the overall structure of the solution in terms of interconnected applications. However, a solution can have multiple system, deployment, and logical datacenter diagrams.
Application Designer is focused on designing applications that fit into a service-oriented architecture (SOA), for example, ASP.NET Web services. The Toolbox in Application Designer contains application prototypes that you use to design applications. Each prototype describes a preconfigured version of a base application type. As a result, dragging a prototype to the application diagram creates an application of a base type that is configured as defined by the prototype.
The Toolbox includes two ASP.NET-based prototypes. ASP.NET Web services are represented by ASP.NET applications with one or more Web service endpoints. As such, the ASP.NETWebService prototype creates an ASP.NET application with a default Web service provider endpoint. The ASP.NETWebApplication prototype creates an ASP.NET application with a Web content endpoint. This topic contains more information about endpoints.
The following list describes other supported application types and their associated prototypes:
- Windows applications: WindowsApplication prototype
- Office applications: OfficeApplication prototype
- External or third-party Web services: ExternalWebService prototype
- External databases: ExternalDatabase prototype
- BizTalk Web services: BizTalkWebService prototype
- Generic applications (for all other application types): GenericApplication prototype
You can also load additional application types and prototypes that might be supplied by Microsoft or third parties, or create your own custom prototypes using the existing base types from applications or endpoints you've added to the application.
Some of the Microsoft-provided application types support a full round-tripping experience with code—notably ASP.NET applications and Windows applications. That is, changes made to code are reflected in the designers, while changes made in the designer are reflected in code. In addition, other application types—notably external Web services, BizTalk Web services, and external databases—can be used to help you define connections from applications to external resources. The GenericApplication prototype provides a simple means to document other kinds of non-supported applications, such as a Unix application or a CICS transaction application. This is a basic form of extensibility. For more advanced extensibility, you can also create new base types and prototypes using the SDK. In many ways, the prototypes in Application Designer resemble Unified Modeling Language (UML) stereotypes, but are much more powerful than the simple labeling mechanism provided by UML.
Let's examine how Application Designer is used by looking at an example. In this example, I'll keep it simple by concentrating on the ASP.NETWebApplication and ASP.NETWebService prototypes that allow you to design a service oriented system. Later, I'll tell you about incorporating other application types into the design.
Figure 2 shows the overall design that I have in mind.
Figure 2. Application Diagram for a Service Oriented Architecture
At the front end are two ASP.NET Web applications, each dedicated to converting an amount into the specified currency. The DollarExchangeApp provides a form that allows an amount to be specified in one currency and converted into US dollars, while the EuroExchangeApp converts a specified amount into Euros.
The next layer in the design is comprised of an ASP.NET Web application that exposes two Web services:
- One to support conversions into US dollars (the USDollarService)
- One to support conversions into Euros (the EuroService)
While each Web service is exposed by a dedicated front-end application in this design, it would be perfectly valid to design a single ExchangeApp front-end application for all currency conversions that is connected to both Web services.
All currency conversions depend on establishing the current market exchange rates between the currencies, so the next layer of the design incorporates an ASP.NET Web application that exposes a Web service to provide this information. The ExchangeRateService is a good candidate for an external Web service to be provided by a third-party, but for now I'll provide my own implementation using the BureauDeChange application.
This example demonstrates two important principles of a service-oriented architecture (SOA). The first is the principle that services may use other services. The second is the principle that these services can be layered according to how application-specific, business-generic, or technology-dependent they are.
The CurrencyConverter provides application-specific services to the DollarExchangeApp and EuroExchangeApp presentation applications. In turn, it makes use of a more generic service named ExchangeRateService provided by the BureauDeChange application.
The example also demonstrates that a single application, the CurrencyConverter, can support multiple services ( USDollarService and EuroService) through multiple provider endpoints, thus mirroring the concept in UML of a single component exposing multiple interfaces.
Designing the Application
As I've said, an application design is constructed by dragging application prototypes from the Toolbox to the diagram. I dragged two ASP.NETWebApplication prototypes (for the DollarExchangeApp and the EuroExchangeApp) and two ASP.NETWebService prototypes (for the CurrencyConverter and BureauDeChange applications). This might leave you wondering why all of the applications shown on the diagram are labeled ASP.NETWebApplication.
The subtlety here is that when you drag an ASP.NETWebApplication prototype to the design surface it is adorned with a default Web content endpoint, whereas when you drag an ASP.NETWebService prototype to the design surface it is adorned with a default Web service endpoint. Thus the ASP.NETWebService prototype is in effect an ASP.NETWebApplication prototype that has the Web content endpoint removed and a Web service endpoint added for your convenience.
Note You can define your own application prototypes based on existing prototypes, and add them to the Toolbox. However, that's beyond the scope of this article.
Having introduced the term endpoint, I'll now define the term.
Endpoints and Connections
Applications communicate through endpoints, and for two applications to be connected together, there must be a provider endpoint at one end of the connection and a consumer endpoint at the other end.
The BureauDeChange application had a default Web service provider endpoint, which I renamed to ExchangeRateService. I connected this up to the CurrencyConverter application simply by pressing the ALT key and dragging a connection line from the provider endpoint to the CurrencyConverter application. This automatically creates the appropriate consumer endpoint on CurrencyConverter.
The CurrencyConverter application had a default Web service endpoint, which I renamed USDollarService and connected up to the DollarExchangeApp in the manner just described. I dragged an additional Web service endpoint from the Toolbox onto the CurrencyConverter, named it EuroService, and connected it up to the EuroExchangeApp.
I deleted the default Web content provider endpoints on the DollarExchangeApp and EuroExchangeApp applications because they aren't needed in this example.
Note You can create as many Web service or Web content endpoints as you like on ASP.NET Web applications, regardless of whether those applications were based on the ASP.NETWebApplication prototype or the ASP.NETWebService prototype. At the end of the day, they're all Web applications.
Web Service Details
Right-clicking a Web service provider endpoint on an ASP.NET application and choosing Define Operations from the context menu allows you to review and change the operations defined for that Web service using the Web Service Details window.
As you can see in Figure 3, I have defined this Web service as having a getExchangeRate operation that returns a Double (the exchange rate conversion factor) based on two currency codes supplied as String parameters.
Figure 3. Web Service Details for ExchangeRateService
You can add additional operations and parameters as required by clicking on the <add operation> and <add parameter> indicators.
For this example, I specified two operations provided by the USDollarService Web service as shown in Figure 4. An amount can be converted into US dollars from Euros or from UK Pounds Sterling.
Figure 4. Web Service Details for USDollarService
The Web service details (not shown) for the EuroService are identical except that a fromDollars operation replaces the fromEuros operation.
With the information I have given you, you should be able to have a go at designing this application yourself using the Microsoft Visual Studio 2005 December CTP (or later). And if you don't feel up to that, you can load up the sample that I have provided for download with the article. Just create a new distributed system solution, remove the default application diagram (.ad) file, and then use the Add Existing Item option to add the ApplicationDesign.ad file that I have supplied.
Settings and Constraints
Just as you can view and amend the Web service details for a Web service provider endpoint, so too can you view and amend settings and constraints for an endpoint or for an entire application. Settings control the behavior of applications or the run-time environment. On an application, constraints constrain the logical server types that can host that application. On endpoints, constraints constrain the types of logical server endpoints to which application endpoints can bind. Figure 5 shows the settings and constraints for the CurrencyConverter application, which by default is constrained to being hosted on an IIS Web server.
Figure 5. Settings and Constraints for CurrencyConverter
This means that when the application is deployed to a server that is represented by a logical server on a logical datacenter diagram (discussed later in this series), that server must have the appropriate IIS Web server settings. Otherwise, the constraint will not be satisfied and the application cannot be successfully deployed to that server.
In Figure 5, the Operating System constraint is not selected because this Web application can be deployed to a server running any operating system as long as the IISWebServer constraint is satisfied.
For an endpoint, a typical constraint would be the WebSiteEndpoint constraint, which constrains an application with a Web service endpoint (the CurrencyConverter) that is to be hosted on a server with a Web site endpoint.
You'll meet the Settings and Constraints editor again in my article on System Designer, which allows settings on applications to be overridden. And you'll really see the implications of setting these values later in this series, when you discover how to evaluate deployment for application systems in a target datacenter using Deployment Designer.
As indicated in Figure 1 of this article, Application Designer represents one piece of the Team Architect jigsaw puzzle. You can see how it is very useful as a means of designing applications.
Tony Loton is an MCP who wears various hats as Principal Consultant/Director of LOTONtech Limited, as Principal Consultant/Head of Microsoft Practice at Cogenture, 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.