This
section describes how Tailspin can use Domain Name System (DNS) entries
to manage the URLs that each group can use to access the service, and
how Tailspin plans to use SSL to protect some elements of the Surveys
application.
1. Web Roles in the Surveys Application
Tailspin uses web roles to
deliver the user interface (UI) elements of the Surveys application.
This section describes the design and implementation of these web roles.
1.1. Goals and Requirements
Three distinct groups of users will access the Surveys
application: administrators at Tailspin who will manage the
application, subscribers who will be creating their own custom surveys
and analyzing the results, and users who will be filling in their survey
responses. The first two groups will account for a very small
proportion of the total number of users at any given time; the vast
majority of users will be people who are filling in surveys. A large
survey could have hundreds of thousands of users filling out a survey,
while a subscriber might create a new survey only every couple of weeks.
Furthermore, the numbers of users filling out surveys will be subject
to sudden, large, short-lived spikes as subscribers launch new surveys.
In addition to the different scalability requirements that arise from
the two usage profiles, other requirements, such as security, will also
vary.
Note:
There are three distinct groups of users who will use the Surveys application.
Although some surveys might be designed for a closed
user group that will require some form of authentication, many surveys
may be open to the general public and will be accessible without any
form of log on. Additionally, all access to the application by
subscribers and administrators will use HTTPS to protect the data
transferred between the application and the client. Public surveys do
not require HTTPS, and this enables the use of custom URLs to access
these surveys by using custom DNS CNAME entries.
Note:
The Windows Azure™ technology platform enables you to deploy role instances to data centers in different geographic locations.
Subscribers and
survey respondents may be in different geographical locations. For
example, a subscriber may be in the U.S. but wanting to perform some
market research in Europe. Tailspin can minimize the latency for survey
respondents by enabling subscribers to host their surveys in a data
center located in an appropriate geographical region. However,
subscribers may need to analyze the results collected from these surveys
in their own geographical location.
1.2. Overview of the Solution
To make it easy for the Surveys
application to meet the requirements outlined earlier, the developers
at Tailspin decided to use separate web roles. One web role will contain
the subscriber and administrative functionality, while a separate web
role will host the surveys themselves. Tailspin can tune each web role
to support its usage profile independently of the other.
Tailspin can host both the subscriber and survey web roles in different geographical locations.
|
Having multiple web
roles in the same hosted service affects the choice URLs that you can
use to access the application. Windows Azure assigns a single DNS name
(for example, tailspin.cloudapp.net) to a hosted service, which means
that different websites within the same hosted service must have
different port numbers. For example two websites within Tailspin’s
hosted service could have the addresses listed in the following table.
| Site A | Site B |
| http://tailspin.cloudapp.net:80 | http://tailspin.cloudapp.net:81 |
Because of the specific security requirements of the Surveys application, Tailspin decided to use the following URLs:
The next sections describe each of these.
1.3. https://tailspin.cloudapp.net
This HTTPS address uses the
default port 443 to access the web role that hosts the administrative
functionality for both subscribers and Tailspin. Because an SSL
certificate protects this site, it is possible to map only a single,
custom DNS name. Tailspin plans to use an address such as
https://surveys.tailspin.com to access this site.
| Remember, you can use DNS CNAME entries to map custom domain names to the default DNS names provided by Windows Azure. |
1.4. http://tailspin.cloudapp.net
This HTTP address uses the
default port 80 to access the web role that hosts the surveys. Because
there is no SSL certificate, it is possible to map multiple DNS names to
this site. Tailspin will configure a default DNS name such as
http://surveys.tailspin.com to access the surveys, but individual
tenants could create their own CNAME entries to map to the site; for
example, http://surveys.adatum.com, http://surveys.tenant2.org, or
http://survey.tenant3.co.de.
It would also be
possible to create separate hosted services for individual tenants that
would also enable subscribers to use custom URLs for their surveys.
However, this approach would complicate the provisioning process and for
small subscribers, it would not be cost effective. Tailspin plans to
scale out the application by adding more role instances within a hosted
service.
| Tailspin will
need to publish some guidance to subscribers that describes how they can
set up their CNAMEs in their DNS settings. |
1.5. Inside the Implementation
To implement the two different websites within a single hosted service, the developers at Tailspin defined two web
roles in the solution. The first website, named TailSpin.Web, is an MVC
2 project that handles the administrative functionality within the
application. This website requires authentication and authorization, and
users access it using HTTPS. The second website, named
Tailspin.Web.Survey.Public, is an MVC 2 project that handles users
filling out surveys. This website is public, and users access it using
HTTP.
The following code example shows the contents of an example ServiceDefinition.csdef file and the definitions of the two web roles:
<ServiceDefinition name="TailSpin.Cloud" xmlns=...>
<WebRole name="TailSpin.Web" enableNativeCodeExecution="true">
<InputEndpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
<InputEndpoint name="HttpsIn" protocol="https" port="443"
certificate="tailspinweb" />
</InputEndpoints>
<ConfigurationSettings>
<Setting name="DataConnectionString" />
<Setting name="DiagnosticsConnectionString" />
</ConfigurationSettings>
<Certificates>
<Certificate name="tailspinweb"
storeLocation="LocalMachine" storeName="My" />
</Certificates>
</WebRole>
<WebRole name="TailSpin.Web.Survey.Public">
<InputEndpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
<InputEndpoint name="HttpsIn" protocol="https" port="443"
certificate="tailspinpublicweb" />
</InputEndpoints>
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
</ConfigurationSettings>
<Certificates>
<Certificate name="tailspinpublicweb"
storeLocation="LocalMachine" storeName="My" />
</Certificates>
</WebRole>
</ServiceDefinition>
Note:
This
example ServiceDefinition.csdef file does not exactly match the file in
the downloadable solution, which uses different names for the
certificates.
Although subscribers can
access the Subscribers website (defined in the TailSpin.Web web role)
only by using HTTPS, Tailspin has also defined an HTTP endpoint. They
will use the URL Rewrite Module for IIS to forward all traffic to the
HTTPS endpoint on port 443. By defining the HTTP endpoint now, in the
future Tailspin can choose to add non-HTTPS content to the website
without deleting the Surveys
application and then re-deploying it. The public website also uses the
URL Rewrite Module and uses it to forward HTTPS traffic to the HTTP
endpoint on port 80 for similar reasons.
Note:
Remember,
you may want to use different SSL certificates when you are testing the
application on the development fabric. You must make sure that the
configuration files reference the correct certificates before you
publish the application to Windows Azure.
| Use the URL
Rewrite Module to forward traffic from unused endpoints. This will
future-proof your applications in case you later decide to use these
endpoints. |
In addition to the two web role
projects, the solution also contains a worker role project and a
library project named TailSpin.Web.Survey. Shared that contains code
shared by both web roles and the worker role. This shared code includes the model classes and the data access layer.
