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.

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 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.