In this article we will see the introduction and usage of Application Designer which is one of the four new distributed designers introduced in the Visual Studio 2005 Team Architect Edition.  First we will see how the Application Designer interacts with the other designers and then we will see an example of designing an application using Application Designer.  The following are the four different designers that come with Visual Studio 2005 Team Architect Edition.

Application Designer	In a distributed system, the applications are defined using the Application designer.
System Designer	The applications defined using the application designer are composed into a deployable system using the system designer.
Deployment Designer	We can evaluate the system deployment using the deployment Designer.  It takes input from both the System designer and the logical datacenter designer for a set of system definitions and logical server definitions.
Logical Data Center Designer	Logical representation of the target data center in which applications/systems will be deployed.

 

Let us see the distributed system design using application designer through an example.

Open Visual Studio 2005 Architect Edition and create a distributed system solution by simply choosing the Distributed System template from the Distributed System Solutions project types while creating new project.  You can do the same by adding the application diagram to an existing solution.

The new solution contains one application diagram with the .ad extension with the same name as the solution.  If I have named the solution as "ApplicationDesignDemo" then the application diagram name would be "ApplicationDesignDemo.ad."  The solution can have only one application diagram because it describes the overall interconnected applications structure, but the solution can have multiple system, deployment and logical diagrams.  In Application Designer, the toolbox includes predefined application prototypes that we can use to define the applications.  An application prototype defines a preconfigured application of a specific application type.  For example, using the ASP.NetWebService prototype from the toolbox can define the ASP.NET application which exposes web services by dragging the prototype to the application diagram.  This action 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.  We will see more about endpoints later.

You can also use custom prototypes by creating your own prototypes using the exiting base types.  You can also use third party prototypes.  All these prototypes can be loaded into the toolbox and you can use that in your application diagrams.  There are some limitations in using these existing prototypes.  The following table describes the different application types and the description for each.  The code generation column indicates the support for code generation by Visual Studio 2005.

 

Application Type	Description	Code Generation
ASP.NETWebApplication	Defines an ASP.NET application.	Yes
ASP.NETWebService	Defines an ASP.NET web services.	Yes
ExternalDatabase	Represents a Database.	No
ExternalBizTalkWebService	Represents an external BizTalk web service.	No
ExternalWebservice	Represents an external Web service as defined by a Web Services Description Language (WSDL) file with a single WSDL binding and has a default Web service provider endpoint.
Genericapplication	Represents an unsupported or unspecified application.  Exists for documentation purposes only.	No
Officeapplication	Defines a Microsoft Office application and supports Excel, Outlook and Word templates.	Yes. Endpoints also support implementation.
Windowsapplication	Defines a Microsoft Windows application and supports console application, Windows application and Windows service templates.	Yes. Web service endpoints and database consumer endpoints on this application also support implementation

 

The following are the advantages of using Application Designer.

·         Reverse-engineer existing solutions

·         Define settings and constraints on applications used in the application designer

·         Visualize and define applications in diagram surface  using prototypes and endpoints

·         Define communication between applications and Web service and database

·         Document other types of communication between applications

·         Expand the set of application types and prototypes you can use to define applications

 

After defining applications, you can perform the following tasks:

·         Evaluate applications for deployment using their development configurations

·         Design reusable application systems as units of deployment using System Designer

·         Implement applications that support implementation

In this section let us start designing a service oriented application using ASP.NETWebApplication and ASP.NETWebService prototypes through an example.  Let us see how we can use the application designer for designing this application.

The example contains one front-end application by which an air ticket agency will get details of the fare from one city to another from different airlines.  This application provides a form for the user to enter the cities' names for the travel and get the fare details from two different airlines that fly between those cities.  The next part in the design is an ASP.NET Web Application that exposes web services that provides the fare details from both the airlines.  The next and third layer in this design is a Web Application that exposes web services that provide the fare details from two different airlines.  These are the external web services provided by the airline companies.  Let us see how we can represent this in the application Designer.

Designing the application

As I have said earlier in part one of this article, create a new distributed system project.  Using the toolbox, drag and drop the prototypes on the application diagram.  For our example, drag one ASP.NETWebApplication prototype (for ticketing agent application) and three ASP.NETWebService prototypes (one for providing the collective fare details and two for different airline applications).

Note: When you drop the ASP.NETWebService prototype on the diagram surface, the prototype is labeled as ASP.NETWebApplication.  The difference here is the endpoints that come with the prototypes.  The ASP.NETWebApplication comes with Web Content as the endpoint, whereas the ASP.NETWebService comes with the Web Service as the endpoints.  The prototype is the same for both except for the endpoints which make the difference.  We can also create our own application prototypes using the existing types as a base and add them to the toolbox.  We will see about creating custom application types in a different article.

Endpoints in Application Design

Endpoints in Applications define the services they provide or the services they consume.  Endpoints also provide the connection point for the application so that we can configure the communication between the applications by connecting their endpoints.  On an application, an endpoint can be a provider or consumer.  Provider endpoint identifies an addressable location at which a service is provided and represents the service as a small solid shape on the application prototype.  Consumer endpoint specifies the requirement for an application to use a service and represents the service as a small hollow shape on the application prototype.

I renamed the Web Service provider endpoint of the AirlineXYZ application to “XYZAirFareService” and the provider endpoint of AirlineABC application to “ABCAirFareService.”   I connected these two provider endpoints to the FareDetails application simply by pressing the ALT key and dragging a connection line from the provider endpoint to the “FareDetails” application.  This automatically creates the consumer endpoint on the “FareDetails” application.  This “FareDetails” application had a default web service endpoint which I renamed to “AirlinesFareService” and connected to the TicketingAgentWebApplication.  As the web content provider is not required, I removed it from the TicketingAgentWebApplication.  You can create as many endpoints as you wish on the ASP.NEtWebApplications and ASP.NEtWebServices application prototypes.

Figure 1

Define Operations for the Web Services

If you right click on the web service provider endpoints, you can see a context menu with an option as “Define Operations.”  On the other hand, if you right click on the web service consumer endpoint, you will get a context menu with an option “View operations.”  We will see how we can define operations using the option “Define Operations” from the context menu.

You can add operations by clicking the option <add operation> and then add parameters by clicking the option <add parameter> indicators.  Let us add the operation “getNetFareXYZ” with two parameters as “fromCity” and “toCity” to get the fare details from the airline XYZ.   That defines the operations for the web service providers.

Figure 2

Figure 3

Settings and Constraints for Applications and Endpoints

You can view and modify the settings and constraints for the web services and endpoints by right clicking on the web service application type or the endpoint and choosing the Settings and constraints options.  Settings are used for setting the run time behavior of the application or the endpoint.  Using constraints on the application type, we can define the logical servers that can host the application.  Using constraints on the endpoints, we can define the types of logical server endpoints to which application endpoints can connect.

Figure 4

In this section we will see how to implement the distributed system using Visual Studio 2005.  In part 2 of this article we have seen the application designer and designed a small application to get the fare details from different airlines using the web services.  We will try to implement the same application using Visual Studio 2005.

By using Visual Studio we can generate the skeleton implementations of the applications in the design.  In the application design surface right click anywhere and select the option “Implement All Applications.”  Selecting this option launches a confirmation dialog for application template and the language for implementation to make sure it is correctly chosen.

Figure 5

 

 

 

Figure 6

Once you click on the "OK" option in the dialog, you can see Visual Studio creating the files for each application in the designer.  Visual studio not only creates the main application files, but also creates the supporting files for each application.  Before selecting the implementation option we can also set application properties and choose the implementation language for each application in the designer.  Each application has its files created in a separate folder.

Figure 7

 

You can also see a file with the extension “sdm,” which is called System Definition Model document.  Each application has one sdm file.  SDM describes distributed systems using a model that includes:

Application Layer – SDM describes this in terms of configured and connected application systems

Application Host Layer – SDM describes this in terms of configured and connected zones and logical servers representing the run time environment

 

By using SDM you can define, configure, document and validate requirements and policies across all layers.  For example, you can specify that an application can require an authentication mode or that certain resources must exist on the hosting server.  The server can also require that the application it hosts must support some authentication mode so that it disables certain features.  We will see more about this file later, but as of now it is of no use.  You can right click on the web service application and select the option “View in Browser” to load the web service and see that in action in the browser.  The methods are not fully implemented and so we cannot test that at this point of time.  Visual Studio only creates the web service skeleton classes and the supporting files.  The developer has to complete the coding work as per the requirement.  However, the good thing is that the hard part of development work is done by the Visual Studio 2005.

Figure 8