Application Infrastructure Architecture

Windows Server System
Reference Architecture
Application Infrastructure
Architecture Blueprint
Published: March 2005

For the latest information, please see http://www.microsoft.com/wssra
Abstract
This WSSRA blueprint focuses on business requirements and architectural considerations for the
infrastructure upon which applications are implemented in an enterprise organization.
Information in this document, including URL and other Internet Web site
references, is subject to change without notice. The entire risk of the use or
the results of the use of this document remains with the user.
The example companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted herein are fictitious. No
association with any real company, organization, product, domain name,
email address, logo, person, places, or events is intended or should be
inferred.
Complying with all applicable copyright laws is the responsibility of the user.
Without limiting the rights under copyright, no part of this document may be
reproduced, stored in or introduced into a retrieval system, or transmitted in
any form or by any means (electronic, mechanical, photocopying, recording,
or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation. Microsoft may have patents, patent applications,
trademarks, copyrights, or other intellectual property rights covering subject
matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you
any license to these patents, trademarks, copyrights, or other intellectual
property.
© 2005 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, ActiveX, BizTalk, MSDN, and Visual C# are
either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
The names of actual companies and products mentioned herein may be the
trademarks of their respective owners.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 •
USA 00
Table of Contents
INTRODUCTION..........................................................................................................................................1
WHO SHOULD READ THIS BLUEPRINT.................................................................................................................1
ENTERPRISE DESIGN................................................................................................................................2
BUSINESS NEED................................................................................................................................................2
ARCHITECTURE DEFINITION................................................................................................................................3
Application Infrastructure Architecture Concepts and Terminology.......................................................4
.NET and COM Component Models...................................................................................................................7
What Applications Need and How Infrastructure Provides It.................................................................8
Internet Information Services..............................................................................................................................9
.NET Framework................................................................................................................................................9
COM+.................................................................................................................................................................9
Message Queuing..............................................................................................................................................10
ARCHITECTURE DESIGN....................................................................................................................................10
Application Deployment Considerations...............................................................................................10
Application Client Types........................................................................................................................12
Thin Clients.......................................................................................................................................................13
Thick Clients.....................................................................................................................................................13
Web Service Clients..........................................................................................................................................13
Transactions...........................................................................................................................................14
Application Infrastructure for the Development Life Cycle...................................................................14
LOGICAL DESIGN............................................................................................................................................16
Design Option 1–Internal Only, 2-Tier..................................................................................................17
Advantages........................................................................................................................................................18
Disadvantages....................................................................................................................................................18
Design Option 2–Internal Only, 3-Tier..................................................................................................19
Advantages........................................................................................................................................................19
Disadvantages....................................................................................................................................................20
Design Option 3–External 2-Tier (Data Source Internal).....................................................................20
Advantages........................................................................................................................................................21
Disadvantages....................................................................................................................................................21
Design Option 4–External 3-Tier (Data Source Internal).....................................................................22
Advantages........................................................................................................................................................22
Disadvantages....................................................................................................................................................23
Design Option 5–External 3-Tier (App and Data Source Internal).......................................................23
Advantages........................................................................................................................................................24
Disadvantages....................................................................................................................................................25
Design Option 6–Internal 2-Tier (Departmental Data Source).............................................................25
Advantages........................................................................................................................................................26
Disadvantages....................................................................................................................................................26
Design Option 7–External 3-Tier (Departmental Data Source)............................................................27
Advantages........................................................................................................................................................27
Disadvantage.....................................................................................................................................................28
Design Option 8–Departmental 2-Tier..................................................................................................28
Advantages........................................................................................................................................................28
Disadvantages....................................................................................................................................................29
Design Option 9–Departmental 2-Tier (Internal Data Source).............................................................29
Advantages........................................................................................................................................................30
Disadvantages....................................................................................................................................................30
Design Option 10–Any Trust Zone to External/Public Web Service......................................................30
Advantage.........................................................................................................................................................31
Disadvantage.....................................................................................................................................................31
ARCHITECTURE DEPENDENCIES..........................................................................................................................32
SERVICE DEPENDENCIES...................................................................................................................................32
STANDARDS AND GUIDELINES...........................................................................................................................32
HARDWARE REQUIREMENTS..............................................................................................................................33
AVAILABILITY.................................................................................................................................................33
SECURITY.......................................................................................................................................................34
Security Design......................................................................................................................................35
Security Lockdowns................................................................................................................................37
SCALABILITY..................................................................................................................................................37
MANAGEABILITY.............................................................................................................................................38
PERFORMANCE................................................................................................................................................38
SUPPORTABILITY.............................................................................................................................................39
CONSOLIDATION..............................................................................................................................................39
INTEROPERABILITY...........................................................................................................................................39
Using Microsoft Windows as an Integration Environment....................................................................40
Interoperability–Web Services...............................................................................................................42
Previous Service Versions......................................................................................................................43
LOCALIZATION................................................................................................................................................43
CDC DESIGN CONSIDERATIONS..........................................................................................................44
BUSINESS NEED..............................................................................................................................................44
Sample Applications...............................................................................................................................44
Architectural Design for Fitch and Mather 7.0..................................................................................................45
Architectural Design for Nile............................................................................................................................45
LOGICAL DESIGN............................................................................................................................................46
Application Architecture Design............................................................................................................46
AVAILABILITY.................................................................................................................................................49
SECURITY.......................................................................................................................................................49
Security Lockdowns................................................................................................................................49
SCALABILITY..................................................................................................................................................49
MANAGEABILITY.............................................................................................................................................50
INTEROPERABILITY...........................................................................................................................................50
SERVICE DEPENDENCIES...................................................................................................................................50
SBO DESIGN CONSIDERATIONS...........................................................................................................51
SUMMARY...................................................................................................................................................52
REFERENCES.............................................................................................................................................53
APPLICATION ARCHITECTURE............................................................................................................................53
COM...........................................................................................................................................................53
COM+.........................................................................................................................................................53
MESSAGE QUEUING.........................................................................................................................................53
.NET............................................................................................................................................................54
Introduction
There are five defined fundamental architectures in Windows Server System™
Reference Architecture (WSSRA). These architectures are:
• Network
• Storage
• Application Infrastructure
• Management
• Security
This blueprint focuses on business requirements and architectural considerations
for the infrastructure upon which applications are implemented in an enterprise
organization. These applications can be externally focused (as in a supply chain
management or an e-commerce application), internally focused (as in a
manufacturing system or a human resource application), or restricted to only
certain users within a department. This blueprint also discusses the deployment
of sample applications in selected representative scenarios, including Fitch and
Mather 7.0, and Nile.
Considerations for application infrastructure are based on patterns of
architecture, design, and deployment described in the Microsoft® TechNet
Patterns and Practices library. For further information, refer to the following URL:
msdn.microsoft.com/practices/
The sections in this blueprint provide different levels of guidance. At the
enterprise level, the guidance deals with the entire organization's architecture.
Such guidance is the appropriate starting point for any architecture design
process, as it addresses the most far-reaching planning issues encountered by
enterprise architects. The subsequent sections provide guidance that is specific
to each of our scenarios. These scenarios are outlined in the Introduction to
Windows Server System Reference Architecture, and a further level of detail is
provided in the Introduction to Architecture Blueprints Blueprint.
Who Should Read This Blueprint

This blueprint is written for enterprise architects working in the area of
application infrastructure design and deployment. Other audiences may find the
blueprint useful in understanding the scope, capabilities, and impact of an
enterprise-class application infrastructure architecture.
Application Infrastructure Architecture Blueprint 1

Enterprise Design
It is necessary to understand a number of enterprise-level architecture design
options before detailed requirements of individual scenarios can be considered.
These design options are expressed in such terms as application availability,
security, scalability, and performance. It is also important to understand the
business need for any technology requirement. Once the business need is
established, an application infrastructure that can support the levels of service
dictated by the application(s) can be designed and deployed.
The following sections describe the business need, and how an application
infrastructure can be assembled to support the most prevalent application
architectural patterns. In addition, a more detailed examination of specific
infrastructure instantiations and corresponding application deployments is
provided.
Business Need
The development, deployment, and operation of enterprise applications require a
rich application infrastructure. Such an infrastructure must meet the
requirements of the information technology (IT) organization for availability,
security, scalability, and manageability and provide facilities for applications to
meet these requirements. Such facilities include:
• Hosting environments for execution of application components.
• Dispatching mechanisms for communication between application
components.
• Management instrumentation to enable service-level monitoring and
problem diagnosis.
• Data storage for both structured and unstructured data.
Application infrastructure needs to provide elements that can be scaled both
horizontally and vertically to support increasing demand. For example, as an
organization's e-commerce site becomes more popular and the number of clients
increases, the application infrastructure should be able to grow to meet the
increasing demand. Infrastructure elements should be highly available, scalable,
and should support the levels of service defined for them. They must also provide
applications with the flexibility to meet their service requirements, which may
include providing mechanisms such as partitioning and clustering.
Depending on the complexity and size of an application, changes to a production
environment can be quite risky without extended testing in a lab that simulates a
production environment. The application infrastructure must be able to support a
separate integration and staging environment where applications can be tested
for full functionality before they are deployed to production servers. The staging
environment may not be of the same scale as the production environment, but
should have all its critical elements.
Security, which is essential for any organization, is also important from the
application infrastructure perspective because certain elements are accessed by
external clients as well as internal ones. Organizations typically maintain
sensitive and confidential data that cannot be compromised at any cost, such as
2Windows Server System Reference Architecture

employee data. A security breach could affect such data, resulting in an impact
on a business-critical application service and leading to significant revenue
losses. It is important that the application infrastructure be capable of countering
any security risks, perceived or real, and that an appropriate fallback be
available in case of a disaster.
Architecture Definition
The WSSRA environment provides the following application infrastructure
elements from Microsoft, each of which helps create a solid foundation for
deploying and operating mission-critical applications:
• Windows Server™ 2003 operating system: Provides a secure,
manageable, and flexible platform.
• The .NET Framework: Provides a secure and manageable execution
environment for application code as well as the means to make
application components available as Web services. The ability to Web-
enable application components provides increased interoperability in
heterogeneous computing environments. In addition, .NET Framework
provides Common Language Runtime (CLR), which supports multi-
language object-oriented programming and a rich set of class libraries for
building both Web and thick-client applications.
• Internet Information Services (IIS): Provides a reliable, high
performance, and configurable HTTP request dispatching service that
serves as the basis for processing both traditional Web requests (such as
Hypertext Markup Language (HTML), Active Server Pages (ASP), and
Common Gateway Interface (CGI) scripting), and .NET Remoting and Web
service requests. IIS also offers Simple Mail Transfer Protocol (SMTP) and
File Transfer Protocol (FTP) facilities.
• COM+: Provides a robust and richly instrumented component-hosting
environment that facilitates efficient component execution, fault isolation,
and management.
• Message Queuing (also known as MSMQ): Provides asynchronous
message queuing services with reliable message delivery.
As the following figure shows, these application infrastructure elements need the
support of low-level software, hardware, and networking services. The figure
depicts how different representative components of the network, hardware, and
application infrastructure work together to run enterprise applications.
Applications such as Microsoft SQL Server™, BizTalk® server, Commerce Server,
Content Management Server, and custom applications use the core services of
application infrastructure elements (such as IIS, COM+, Message Queuing, and
UDDI) running on Windows Server 2003. In addition, the applications and
application infrastructure elements use the network infrastructure to provide the
underlying transport for information transfers.

CustomApplications
Application
Commerce Content Management
SQL Server BizTalk
Server Server
Active
Network Services DNS DHCP IIS COM+ MSMQ UDDI
Directory
Application
Infrastructure
Elements
Windows Server 2003 / .NET Framework
Servers Storage Devices Hardware
Other Network
Routers Leased Lines Switches Network Infrastructure
Devices
Figure 1. Components of an Enterprise Application

More detailed guidance on application infrastructure services is provided in the
following Service Blueprints:
• Web Application Services Blueprint
• Middleware Services Blueprint
• Data Services Blueprint
For an introduction to designing and deploying applications based on concepts of
application layering and deployment tiers, refer to the Application Architecture
for .NET: Designing Applications and Services document at the following URL:
msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp
Application Infrastructure Architecture Concepts

and Terminology
This blueprint provides an overview of the various application infrastructure
elements, which are used together to provide core application services. It is
intended to give system administrators a basic understanding of some common
application architectures so they can better understand the infrastructure needs
of applications they support in their enterprise. This blueprint does not discuss
the details of how to design applications. For information on application design,
visit the Microsoft Patterns and Practices Web site at the following URL:
msdn.microsoft.com/practices
When discussing application infrastructure architecture, it is necessary to refer to
an application in terms of its architectural elements. This blueprint uses the
canonical application architecture concepts and terminology laid out in the
Microsoft TechNet Application Architecture for .NET document at the URL
referenced in the previous section. TechNet defines a number of terms relating to
application architecture that are used extensively in this blueprint, such as
component, layer, tier, and assembly. For convenience, definitions for these
terms are reproduced here.
A component refers to a logical software module, such as a .NET or COM
component. A collection of components makes up an application. These

components may be further grouped into various types of components, which
determine the layer to which each component belongs.
A layer refers to a logical partition of an application. This partition consists of
components of a given type. The adopted model partitions an application into
three layers according to the application duties performed by the component
types of each layer. The three layers are:
• Presentation layer: Includes component types such as User Interface
(UI) and UI Process components, which deal primarily with the creation of
UI elements and encapsulate the logic that handles the user’s navigation
of the UI.
• Business layer: Includes component types such as Business Workflow,
Business Component (BC), Business Entity, and Service Interface (SI),
which encapsulate the business processes and rules that form the core of
the application.
• Data layer: Includes component types such as Data Access logic (DA)
and Service Agent (SA) components, which encapsulate the complexities
of dealing with data access for specific data sources (DS) and Web
services, respectively.
A tier is a logical entity, comprised of one or more physical hosts or devices, to
which the logical layers are deployed. Sometimes the physical tiers correspond
directly to the logical layers (for example, Web tier for the presentation layer,
application tier for the business layer, and data tier for the data layer) and
sometimes multiple layers are deployed to a single tier.
The following figure depicts a hypothetical scenario where the presentation layer
is deployed to the Web tier and the business and data layers are deployed to the
application tier.

` Clients `
UI Components
UI Process Components
PresentationLayer
WebTier
Service Interfaces
Business Business
Business Entities
Workflows Components
Business Layer
Data Access Logic

Service Agents
Components
Data Layer
ApplicationTier
Data Sources Services

DataTier
CDC
Figure 2. Application Layers and Physical Tiers

Assemblies are the building blocks used by the .NET Framework to solve the
dynamic-link library (DLL) versioning and deployment issues commonly referred
to as “DLL hell.” In many ways, assemblies equate to DLLs in the COM world. In
essence, assemblies are "logical DLLs" in that they have no strict counterpart in
COM, though they are similar to a COM server module (.exe or .dll file). For more
information about assemblies, see the Middleware Services Implementation
Guides.
In this blueprint, and particularly in the figures depicting design options for
specific scenarios, a reference to each layer’s components may be taken to be an
implicit reference to the layer itself. For example, a reference to BC and/or SI
components implies a reference to the business layer while a reference to UI
components implies a reference to the presentation layer.
This blueprint is primarily concerned with how these application layers relate to
application infrastructure elements, and also with the design choices that drive
the deployment choices.

.NET and COM Component Models
The Windows Server 2003 environment supports coexistence of and
interoperability between applications developed for both the .NET and COM
component models.
The two component models differ in several respects. However, the majority of
application infrastructure issues arise from the following aspects of the
components model:
• Registration of components so that they can be found at run time
• The context in which a component runs relative to the context of its client
• The execution hosting environment for a component
To be referenced at run time, both COM and .NET components must be made
“visible” to their respective run time services. For COM components, this means
registering them, which means recording information about their location in the
registry. For .NET components, this means placing the components in one of
several locations where the .NET run time is configured to look for them.
Components must run in a hosted environment. For example, COM+ may provide
the component execution hosting environment for COM components while the
.NET runtime provides the component execution hosting environment for .NET
components. Both of these execution hosting environments are configurable and
pertain to the deployed infrastructure; configuration details for each are provided
in the Middleware Services Implementation Guides.
For details of the COM component model, refer to the “Microsoft Component
Services” document at the following URL:
www.microsoft.com/com/wpaper/compsvcs.asp
For details of the .NET component model, refer to the Middleware Services
Blueprint.
Additional considerations stem from the use of remoting and proxies, which are
described in the following sections.
Inter-Component Communication
In either component model, a component is considered to be running “remotely”
from its caller if it runs outside of its caller’s execution context—for example, on
a different computer or within a different execution space (process) on the same
computer. For COM, the execution context or container where a component runs
is known as an apartment, whereas for .NET the execution context of a
component is known as an Application Domain (AppDomain). When two
components that are running in different execution contexts communicate with
each other, they require the services of application infrastructure to complete the
communication. This may involve communication that spans machines,
networks, and even location boundaries. In COM, this may take the form of
Distributed COM (DCOM), while in .NET it may take the form of .NET Remoting or
Web services. In either case, there will be some type of application configuration
that is required on both client and server machines. The type of configuration will
vary by application. In the case of .NET-connected applications, configuration
information may take the form of an extensible markup language (XML) file that
is distributed with the application (such as a web.config file), while DCOM may

involve the use of a configuration tool such as Dcomcnfg.exe or a setup program
exported from COM+.
For details about remoting in .NET, refer to the “.NET Framework” section in the
Middleware Services Blueprint. Details about remoting and proxies in COM can be
found in the previously referenced Microsoft Component Services document at:
More information about .NET application domains can be found at:
msdn.microsoft.com/library/en-us/cpguide/html/cpconapplicationdomains.asp
What Applications Need and How Infrastructure

Provides It
In general, applications share the following basic requirements:
• The ability to interact with their clients, whether they are interactive
clients or software clients (for example, using Web services).
• A place to perform the processing requested by their clients.
• The ability to programmatically interact with other applications as callable
services.
• A place to store durable data.
Interacting with clients involves receiving requests, dispatching them to the
appropriate piece of application code, and routing the application’s reply back to
the client. For Web-based applications (including those with browser clients and
those with Web service clients), IIS provides the ability to interact with clients.
For applications that service COM clients, COM+ provides this capability.
The infrastructure boundaries between request dispatching and request
processing are often blurred. For example, IIS provides both client interaction
capabilities (interactive clients and software clients), as well as several models
for request processing, some of which delegate this specific duty to both COM+
and .NET Framework facilities. In general, the .NET Framework and COM+ can be
thought of as the places where request processing occurs; a more precise
description requires a detailed understanding of these infrastructure facilities.
Applications can interact with each other depending on how similar the two
applications’ implementations are. The problem of foreign system interoperability
has many solution techniques, including the rapidly emerging method that is
based on the use of Web service protocols. The .NET Framework provides
extensive support for the consumption and exposure of application functionality
through Web services. However, there are other foreign system interoperability
techniques—for example, the use of Host Integration Server 2000 for
interoperability with IBM systems such as the S/390 and AS/400.
Note that these principles hold true for both synchronous and asynchronous
request processing. In the case of asynchronous processing, the processing of a
request is detached from the interaction with the client that submitted the
request.
Specific Microsoft technologies are covered in the following paragraphs.

Internet Information Services
IIS plays several roles in the application infrastructure architecture and performs
the following functions:
• Serves static content to UI clients.
• Dispatches requests for dynamic content (ASP/ASP.NET, CGI, and ISAPI).
• Hosts execution of .NET remoted components.
• Dispatches Web service requests (ASMX).
For more information about IIS, refer to the Web Application Services Blueprint.
.NET Framework
The .NET Framework refers to the Common Language Runtime (CLR) that
manages the execution of application code and the .NET Framework class
libraries that applications call for common programming services such as data
manipulation, communications, threading, and data access. In addition, .NET
defines a cross-language object-oriented programming model and the native
ability to make available application capabilities as Web services.
For more information about the .NET Framework, refer to the Middleware
Services Blueprint.
COM+
COM+ provides an execution environment in which components can be run. It
also provides a set of services that are critical for scaling applications to support
large numbers of users, including the following:
• Distributed transaction coordination, which ensures the integrity of
databases.
• Queued components, which provide asynchronous execution and can help
applications handle network failures.
• Object pooling, which allows applications to support larger numbers of
users than would otherwise be possible.
COM+ defines the notion of a “COM+ application” as the administrative unit to
which the deployed .NET and traditional COM components belong. On a given
computer, there can be one or more COM+ applications, and each application
can host one or more components. A given component cannot belong to more
than one COM+ application unless COM+ partitioning is enabled. For more
information on COM+ partitioning, refer to COM+ Partitioning at the following
URL:
msdn.microsoft.com/library/en-us/cossdk/htm/pgservices_partitions_1gdb.asp
Some characteristics of a component’s execution environment are properties of
the COM+ application to which it belongs (for example security context), while
others are properties of the component itself (for example, transactional and
poolable capabilities). Additional information on various COM+ services can be
found at:
msdn.microsoft.com/library/en-us/cossdk/htm/pgservices_partitions_1gdb.asp

Message Queuing
Message Queuing (also known as MSMQ) provides asynchronous queuing
services that allow applications to exchange messages in a time-decoupled
fashion. The typical application uses of Message Queuing include:
• The COM+ queued components facility, which uses Message Queuing to
provide asynchronous component method execution.
• Time-decoupling a request from its execution for tasks such as long
running report generation.
• Request handling in a disconnected environment (for example,
intermittent connectivity with mobile clients).
• Reliable, transactional forwarding of data in a disconnected environment.
For more details about Message Queuing, refer to the “Message Queuing
Overview” document at:
msdn.microsoft.com/library/en-us/msmq/msmq_about_overview_1p9z.asp
Architecture Design
The design of an application infrastructure architecture must meet several
competing types of requirements. Issues such as availability, security, scalability,
and manageability must be addressed while accommodating the prerequisites of
application deployment and transaction handling. Design choices that meet one
subset of requirements may not meet other requirements and often have
consequences that affect the application design. For example, some techniques
for increasing availability or scalability of an application entail replicating layers
of the application on multiple, clustered nodes. However, implementing
replication can introduce security challenges and increase the complexity of
managing the deployed application.
Most of the requirements for application infrastructure, including its installation,
configuration, and deployment of application elements (code, configuration data,
application data, and schemas) arise from the ways in which the applications use
the infrastructure, as well as from the particular architectural patterns upon
which the application is based. In addition, the client types that the application
supports need to be considered. Finally, the characteristics of how transactions
are managed within the application and the way in which the application is
developed can affect the application infrastructure architecture. These
considerations are addressed in the following sections.
Application Deployment Considerations

Application deployment requires flexibility to meet requirements for availability
(load balanced and failover clustering), security (physical tier separation,
firewalls/trust zones), scalability (load balanced clustering), and manageability
(COM+ partitions, IIS application pools). These requirements drive most
application infrastructure installation and configuration challenges.
There are a number of ways in which an application can be deployed. Generally,
variations consist of a relatively small number of distinct scenarios showing how
the application layers are deployed to physical tiers (possibly clustered) with

optional intervening trust zone boundaries (often supported by firewall services).
There are two kinds of clustering that are applicable to application deployment:
• Load balanced clustering: Refers to the cloning of a "read-only"
application layer (for example, one that includes UI components) across
2n nodes that are accessible by a single virtual IP address. This kind of
clustering provides scale out capabilities and improved availability. In load
balanced clustering, when a request is in progress on a given node and
that node fails, the request is not determined although further requests do
not come to that failed node and instead are sent to other healthy nodes.
• Failover clustering: Refers to the clustering of a “read-write” application
layer (for example, one that includes a database) to provide high
availability. In failover clustering, when a request is in progress on a given
node and that node fails, the processing of that request is terminated and
the transaction is rolled back.
Trust zones, or security zones, refer to the network of computers bounded by
firewalls through which a limited set of communication protocols (typically,
HTTP/HTTPS) are allowed to flow. These zones present barriers against attacks
that can compromise the security of code and data and are typically defined by
the organization’s security staff. Most enterprise scenarios are covered if three
trust zones are assumed:
• Perimeter trust zone
• Internal trust zone
• Departmental trust zone
The perimeter and internal trust zones are fairly well understood; the notion of a
departmental trust zone applies to a number of situations, such as where
sensitive departmental data is shielded even from the internal trust zone (Human
Resources data would be a good example) or where legal/regulatory
requirements demand that certain kinds of data be shielded from the internal
network. In any case, the term “departmental trust zone” means a trust zone
contained within the internal trust zone. For more information about trust zones,
refer to the Security Architecture Blueprint.
Whether implementing a public-facing Internet site, an internal enterprise
application, a restricted access departmental application, or an application that
contains elements from each of these, the approaches for deploying application
architecture layers on a physical application infrastructure generally fall into
three categories:
• Physically separate tiers: In this category, adjacent application
architecture layers are deployed on physically separate tiers, including
situations where the physical tiers are separated by firewalls. This
approach introduces numerous application infrastructure configuration
issues. If the tiers are within the same trust zone, matters are often more
simple. If they are in different trust zones, the intervening firewall
introduces requirements that pertain to security and remoting that must
be addressed by the application architect working with the network
administrator. Also, if the different trust zones are not adjacent (for
example, the perimeter and departmental trust zones), the routing of
traffic across multiple trust zones must be considered while designing the
applications.

• Clustered tiers: In this category, an application layer is deployed to a
tier that is clustered for either load balancing or failover purposes. An
example of this would be where the components of the business layer are
deployed to an application server that is providing component load
balancing. This approach presents challenges in managing the
components and restricts the state in which they can be kept.
• Consolidated tiers: In this category, multiple layers are deployed to the
same physical tier. This includes the option of deploying multiple
applications on a given physical tier, referred to as “server consolidation.”
Whether or not the tier is clustered, this approach presents challenges in
the management, security, and performance optimization of these
applications.
Given these mechanisms (such as clustering and zones) and approaches to
deploying applications, there are numerous application deployment scenarios to
consider. The scenarios arise from different choices that are made in the physical
deployment of the application architecture layers. These scenarios will have
different characteristics including:
• Whether the application is external facing, internal facing, or for restricted
internal access.
• Whether the application serves interactive clients and/or programming
clients (refer to the “Application Client Types” section).
• Whether the application requires isolation of layers for independent
scaling, failure isolation, or network traffic isolation.
Scenarios also reflect choices regarding certain adjacent application architecture
layers running on the same or different servers and whether the adjacent servers
are separated by a firewall. For further information on this topic, refer to the
“Physical Deployment and Operational Requirements” chapter of the Application
Architecture for .NET document at the following URL:
msdn.microsoft.com/library/en-us/dnbda/html/AppArchCh4.asp
Application Client Types

Applications running in an enterprise data center are accessed by various types
of clients. Application architects consider business requirements as well as
infrastructure requirements (such as security and connectivity) when
determining the type of client to use. Security considerations include criteria
such as authentication mechanisms (for example, anonymous, integrated
Windows, Passport, ASP.NET-based forms, and user database) as well as the
location where the client will be run, such as from the internal trust zone or the
Internet. Connectivity considerations include criteria such as the network
bandwidth available to the client; for example, clients at branch offices may have
slower wide area network (WAN) connections than clients connecting from the
internal enterprise network.
There are several client types that can be considered, each of which may affect
the application infrastructure architecture. The major client types are:
• Thin client (Web browser) with application logic and data hosted on
servers.

• Thick client with differing portions of application logic (and possibly data)
hosted on the client. For example, this could include UI-related logic and
some user preference data.
• Software client accessing a Web service interface where the application
presents a program-callable interface that is meant to be consumed by
other software (no UI is served from the server).
When a client issues a request to an application, whether it is an interactive
client at a Web browser or a service client, the request may be processed
synchronously and the response returned to the client or asynchronously with an
acknowledgment returned to the client that the request has been accepted. An
asynchronous request may be processed at any time after it is accepted by the
application.
Thin Clients
In the case of a thin client, client computers access the application from a Web
browser. The browser essentially formulates and posts HTTP/HTTPS requests to
the Web server (for example, IIS) and then renders the UI that is sent to it from
the server in response to that request. The Web server serves as the HTTP/HTTPS
request dispatching facility; this means that it routes the request to the proper
piece of application code and routes the application’s response back to the
proper client. The application code that handles these HTTP/HTTPS requests
could be an ISAPI extension or filter (.dll), a traditional ASP page (.asp), an
ASP.NET page (.aspx), or a Web Service handler (.asmx). In any case, these initial
handlers of an HTTP/HTTPS request are typically referred to as the presentation
layer. This layer, aside from managing the user interface, also delegates the
processing of business functions to components of the business layer. The
business layer components may actually run in the environment of their caller, or
they may run on a separate computer. In either case, the data layer would
typically run on a separate set of failover clustered servers.
Thick Clients
In the case of a thick client, the presentation layer and possibly some portion of
the business and data layers may run in the client process on the client
computer. Thick client implementations require some type of client installation.
The introduction of the .NET Framework has greatly simplified and reduced the
risks associated with deploying thick client applications to user’s desktops. For
more information about .NET-connected thick client applications, refer to the
Middleware Services Blueprint.
Web Service Clients

In the case of a software client accessing a Web service interface, the client
formulates a Web service request using the Simple Object Access Protocol
(SOAP), sends it to the Web service, and waits for a response. The Web service
consists of a thin layer that typically runs under IIS and delegates the processing
of the request to a component in the business layer that delivers the Web service
functionality. Web services essentially provide access to application components
over HTTP, and the spectrum of Web service clients can include Web applications
that connect from Web browsers, thick client applications, and server
applications without user interfaces.

Transactions
Transactions involve grouping of separate database operations together to
guarantee the integrity of the underlying data. As an example, the process of
transferring money from one bank account to another consists of two database
updates—a debit from one account and a credit to another—which must succeed
or fail as a unit. If the debit succeeds while the credit fails, money is destroyed,
making customers unhappy. Conversely, if the credit succeeds while the debit
fails, money is created, definitely making the bank unhappy.
The ways in which transactions are handled by an application influence the
selection of the application infrastructure elements that are used. For instance,
the COM+ Transaction Service intervenes on the behalf of components to
manage transactions that may update one or more databases.
This concept of transactions also applies to a case where several resources must
be updated in a single unit of work. For example, an application may update
some portions of a database, send a Message Queuing message, and
communicate with an existing transaction through COMTI in a single transaction.
This transaction would span three separate resource managers: SQL Server,
Message Queuing, and IMS. In the Windows Server 2003 environment, the
Microsoft Distributed Transaction Coordinator (MSDTC) provides the cross-
resource transaction coordination, which ensures the integrity of this distributed
unit of work. The use of MSDTC across computer boundaries requires that MSDTC
be available and running on all the computers enlisted in the transaction. In
addition, certain TCP/IP ports must be configured to allow MSDTC to
communicate with the appropriate resource managers. For details on configuring
MSDTC to work across a firewall, refer to Microsoft Knowledge Base Article
250367 at:
support.microsoft.com/default.aspx?scid=KB;EN-US;q250367
In Web services, the WS-Transaction mechanism for doing transactional work
with Web services is emerging as a standard. For more information on WS-
Transaction, refer to:
msdn.microsoft.com/library/en-us/dnglobspec/html/ws-transaction.asp
Maintaining large numbers of records requires methods to access and update the
records in an efficient manner. Since some of this data may contain sensitive
information, security measures may need to be taken. Also, data services should
be highly available to meet the applications' needs for continuous data access.
For more details, refer to the Data Services Blueprint.
Application Infrastructure for the Development

Life Cycle
Application development, deployment, and hosting in a large IT organization
often involve separate development teams working in parallel on numerous
applications for deployment to a shared hosting environment. This kind of
dynamic environment demands an orderly process for promotion of application
elements from the initial development stages to a highly stable and tightly
managed production environment.

The ways in which an application is exercised at the various stages of its life
cycle and deployment schedule require several different parallel instantiations of
the application. These instantiations or environments go by many names in
different organizations, but the following names are commonly used:
• The development environment is where unit level development is
done. Therefore, software and data structures tend to be volatile in this
environment. It is here that the developer is at liberty to modify the
application module under development and its test environment to suit
unit level development needs. In this environment, developers typically
work solely on development workstations where they often have full
administrative rights. The development environment is a “sandbox”
environment where developers are free to use various application
infrastructure elements without the constraints, for instance, of the
security that will exist in other environments. This allows developers to
focus on building application logic and learning how best to use the
various application infrastructure elements available without limitations
imposed by the environment.
• The integration environment is where application units (software
modules, data schemas, and data content) are first assembled and then
tested as an integrated suite. This environment is also volatile but is much
less so than the development environment. The objective here is to force
coherence among the independently developed modules or schemas. This
is typically an environment where developers do not have all the
permissions that they had in the development environment. As a result,
this is often the first time that issues such as installation, configuration,
and security requirements for the eventual target infrastructure are
addressed.
• The test environment is where a “release candidate” grade version of
the application is run through testing exercises. It is as tightly controlled
as the production environment and also substantially less volatile than
integration. The objective here is to assume relative stability of the
integrated application and test its stability, correctness, and performance.
This environment is usually off limits to developers. Deployment and
updates to applications in this environment are controlled by the test
team and are often done by a member of the build or infrastructure
teams.
• The staging environment is where an application resides after it has
been fully tested in the test environment. It provides a convenient location
from which to deploy to the final production environment. Because the
staging environment is often used to perform final tests and checks on
application functionality, it should resemble the production environment
as closely as possible. For example, the staging environment should not
only have the same operating systems and applications installed as the
production computers, but it should also have a similar network topology
(which the testing environment might not have). Usually, the staging
network environment mimics the production environment in all respects
except that it is a scaled down version (for example, it may have fewer
cluster members or fewer processors than your production servers).
• The production environment is where the application is actually used
by the organization; it is the least volatile and most tightly controlled.

` ` ` ` ` ` ` `
` ` `
` ` `
Development
Environment IntegrationEnvironment TestEnvironment StagingEnvironment ProductionEnvironment
DevelopmentManages Test/QualityAssurance InfrastructureManages

Manages
Figure 3. Application Deployment Environments

Every IT organization may not have all of these environments because of cost
constraints, but the separate roles that each plays are common to all application
development and deployment activities.
The configuration and deployment of the application infrastructure will vary
depending upon the different needs of individual applications. Other elements
you should consider are:
• Firewalls: Even if you do not have firewalls deployed in non-production
environments, you should plan ahead and take into account port
restrictions and direction of communication while testing in the test
environment. Software products that emulate firewalls are available and
are a good addition to the test environment. Application architects as well
as network administrators should talk to their security administrator to
determine the restrictions that may be in place.
• Network topology: Your staging environment may be smaller than the
production environment, but you should work with your network
administrator to get the network topology as consistent to the production
environment as possible to ensure that network communication works as
expected.
• Processor count: If your target environment has multiple processors,
you should test your application on multiple processors to be sure that any
multithreaded code works as expected.
• Load balanced clustering: If your target environment has load balanced
clustering, you should test your application in an environment that has
load balanced clustering.
• Failover clustering: If your target environment has failover clustering,
you should test your application in an environment that has failover
clustering.
Logical Design
As mentioned previously, application deployment must be flexible to meet
availability, security, scalability, and manageability requirements. Differing
degrees of deployment flexibility result in different options for the application
infrastructure installation and configuration. Because applications are designed,
developed, and deployed to meet specific business and infrastructure
requirements for each enterprise, the number of possible application deployment
combinations is very large. This section illustrates some common deployment
configurations to provide a basis for discussion of the elements described earlier.

Just as there are numerous methods of deploying applications due to your
specific requirements, there are also many ways that applications can be
secured. The illustrations that follow depict various common communication
mechanisms, including the ports that are commonly used. For specific
information regarding the security of .NET applications, you are strongly
encouraged to read the Building Secure ASP.NET Applications: Authentication,
Authorization, and Secure Communication document, which can be found at:
msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp
Design Option 1–Internal Only, 2-Tier

In the Internal Only, 2-Tier design, the entire application runs within a single trust
zone (specifically, the internal trust zone). The presentation and business layers
run on a single tier (that is, the same computer or cluster), which is a combined
Web/App tier. This design would be appropriate for an application whose clients
are within the company, although the application itself may leave the internal
trust zone to access external services, such as Web services.

SOAP - HTTP (80)/HTTPS (443)
PUBLIC
INTERNET

PROXY
Internal Trust Zone
Thick Client Web Client
SOAP - HTTP (80)/HTTPS (443) HTTP (80)/HTTPS (443)

Load Balanced
Cluster
Web/App - UI/SI/BC/DA/SA
SQL (1433)
Internal SQL
RDBMS
RDBMS
Figure 4. Internal Only, 2-Tier Design
Advantages
In the Internal Only, 2-Tier design, most elements of the application run on a
single tier (except the database). Therefore, all cross-tier and cross-firewall
issues are eliminated, resulting in the following advantages:
• There are no cross-server remoting issues.
• The deployment is simplified.
• It is simpler to determine availability.
Disadvantages
The disadvantages of running both the presentation and business layers on the
same tier in the Internal Only, 2-Tier design include:
• The layers cannot be independently scaled.
• The layers are not availability independent.

Design Option 2–Internal Only, 3-Tier
In the Internal Only, 3-Tier design, the entire application runs in the internal trust
zone, but the presentation and business layers run on separate Web and
application tiers, respectively. This design allows independent scaling of the two
layers. However, running the two layers on different tiers requires configuration
of .NET Remoting between the two tiers.

PUBLIC
INTERNET
PROXY
Internal Trust Zone


HTTP (80)/HTTPS (443)
Load Balanced Load Balanced

Cluster Cluster
.NET Remoting HTTP(80)
Internal SQL
Web - UI/SI App - BC/DA/SA
SQL(1433)
RDBMS
RDBMS
Figure 5. Internal Only, 3-Tier Design
Advantages
The advantages of the Internal Only, 3-Tier design option include:
• Independent scaling of presentation and business layers is feasible.
• Fault isolation and insulation from resource abuse is provided between
presentation and business layers.
• Independent availability of presentation and business layers is allowed.

Disadvantages
The disadvantages of the Internal Only, 3-Tier option include:
• Remoting configuration between UI and BL layers is required.
• Security configuration between presentation and business layers is
required.
• Performance is affected by network latency (because calls need to be
made between the presentation and business layers).
• Problem diagnosis becomes more complex.
Design Option 3–External 2-Tier (Data Source

Internal)
In the External 2-Tier (Data Source Internal) design, the presentation and
business layers run in the perimeter trust zone on a combined Web/App tier,
connecting to a data source running in the internal trust zone. This requires ports
to be opened for SQL Server and DTC in the firewall between the perimeter and
the internal trust zones.

Web Service Web Client PUBLIC
Client INTERNET

PROXY
Firewall
Perimeter Trust Zone
Load Balanced
SOAP-HTTP(80)/HTTP(443) Cluster
HTTP (80)/HTTPS(443)
SQL (1433)
DTC (rpc ports)
Firewall
Internal Trust Zone
SQL
SQL
Internal SQL
RDBMS
RDBMS RDBMS
RDBMS
Figure 6. External 2-Tier (Data Source Internal) Design
Advantages
The advantages of the External 2-Tier (Data Source Internal) design option
include:
• The advantages identified in option 1 of having the presentation and
business layers run on the same tier.
• The firewall provides an additional security barrier between the untrusted
security zone and the data source.
Disadvantages
The disadvantages of the External 2-Tier (Data Source Internal) design option
include:
• The disadvantages identified in option 1 of having the presentation and
business layers running on the same tier.
• Firewall configuration for access to database is required.

• Application deployment is more complicated due to the intervening
firewall.
Design Option 4–External 3-Tier (Data Source

Internal)
In the External 3-Tier (Data Source Internal) design, the presentation and
business layers run in the perimeter trust zone on separate Web and App tiers,
the latter connecting to a data source running in the internal trust zone.
HTTP (80)/HTTPS (443) SOAP - HTTP (80)/HTTPS (443)

Web Client PUBLIC
INTERNET

Web Service
Client
Firewall
PROXY

SOAP - HTTP (80)/HTTPS (443) SOAP - HTTP (80)/HTTPS (443)
Cluster Cluster

SQL (1433)
DTC (rpc ports)
Firewall
Internal Trust Zone
SQL Internal SQL
RDBMS RDBMS
RDBMS RDBMS
Figure 7. External 3-Tier (Data Source Internal) Design
Advantages
The advantages of the External 3-Tier (Data Source Internal) design option are
the same as the advantages identified in option 2, with respect to presentation
and business layers running on different tiers.

Disadvantages
The disadvantages of the External 3-Tier (Data Source Internal) design option
include:
• Remoting configuration between presentation and business layers is
required.
• Component hosting choice (IIS or custom) is required.
required.
• Performance is affected due to network latency between presentation and
business layers as well as between perimeter and internal trust zones
(from either the presentation or business layers).
• The application deployment is more complicated due to intervening
firewall.
Design Option 5–External 3-Tier (App and Data

Source Internal)
In the External 3-Tier (App and Data Source Internal) design, the presentation
layer runs on the Web tier in the perimeter trust zone, the business layer runs on
the App tier in the internal trust zone, and the data source is in the internal trust
zone as well. This could apply to a public-facing Web site or service that runs the
presentation or business layers in the perimeter yet needs to run business layer
components on the internal network for security reasons.

PUBLIC
INTERNET
Web Service Web Client

Client
PROXY

Firewall

Load Balanced
Cluster
SOAP-HTTP(80)/HTTP(443)
HTTP (80)/HTTPS(443)
Web - UI/SI
.NET Remoting HTTP (80) SOAP - HTTP (80)/HTTPS (443)

Firewall
Internal Trust Zone
Internal SQL Load Balanced

.NET Remoting HTTP (80) Cluster
SQL (1433)
RDBMS
RDBMS
App - BC/DA/SA
Figure 8. External 3-Tier (App and Data Source Internal) Design
Advantages
The advantages of the External 3-Tier (App and Data Source Internal) design
option include:
• Independent scaling of presentation and business layers is allowed.
• Fault isolation and insulation from resource abuse between presentation
and business layers is provided.
• Independent availability of presentation and business layers is allowed.
• Business logic and sensitive metadata (database connection strings, for
example) is kept in a more secure setting.

Disadvantages
The disadvantages of the External 3-Tier (App and Data Source Internal) design
option include:
• Remoting configuration between presentation and business layers is
required.
required.
• The intervening firewall places additional constraints on security between
presentation and business layers, resulting in lack of domain trust
between the layers.
• Performance is affected due to network latency.
Design Option 6–Internal 2-Tier (Departmental

Data Source)
The Internal 2-Tier (Departmental Data Source) design option is a variation of
design option 1. In this design option, the application runs in the internal trust
zone and goes through a firewall to a departmental data source, access to which
is restricted. An example of this is an internal application that allows users to see
filtered versions of their own otherwise restricted access human resources data.
This option does not differ significantly from other options where applications
must go through a firewall to reach a data source.

PUBLIC
INTERNET

PROXY
Internal Trust Zone
SOAP - HTTP (80)/HTTPS (443) Load Balanced

Web Service Cluster
Client

Web Client
SQL (1433)
DTC (rpc ports)
Firewall
Department Trust Zone
SQL
RDBMS
RDBMS
Figure 9. Internal 2-Tier (Departmental Data Source) Design
Advantages
The advantages of the Internal 2-Tier (Departmental Data Source) design option
are similar to those of design option 1. In addition, this design option provides
application access to sensitive departmental data without allowing the users to
directly access the data.
Disadvantages
The disadvantages of the Internal 2-Tier (Departmental Data Source) design
option are the same as those identified in design option 1.

Design Option 7–External 3-Tier (Departmental
Data Source)
In the External 3-Tier (Departmental Data Source) design, the presentation layer
runs on the Web tier in the perimeter trust zone while at least one data source
that must be accessed is in the departmental trust zone. There are two ways in
which the application can access the data source: portions of the application
code must go through two firewalls (perimeter->internal and internal-
>departmental) or they must use components running in the internal trust zone,
which requires remoting between the perimeter and internal trust zones with
data source access between the internal and departmental trust zones.

Web Client PUBLIC
INTERNET

Web Service
Client
Firewall
PROXY

Load Balanced SOAP - HTTP (80)/HTTPS (443) Load Balanced
Cluster Cluster
SQL (1433)
DTC (rpc ports)

Firewall
Department Trust Zone
SQL
RDBMS
RDBMS
Figure 10. External 3-Tier (Departmental Data Source) Design
Advantages
The advantages of the External 3-Tier (Departmental Data Source) design option
are the same as those identified in design option 6.

Disadvantage
The primary disadvantage of the External 3-Tier (Departmental Data Source)
design option is that it becomes more of a challenge to address tiers in the
departmental trust zone from tiers in the perimeter trust zone.
Design Option 8–Departmental 2-Tier

In the Departmental 2-Tier design, an application that is specific to a department
runs entirely within the departmental trust zone. This is not very different from
the Internal 2-Tier design.

PUBLIC
INTERNET

PROXY
Departmental Trust Zone

Load Balanced
Cluster
SQL (1433) Web/App - UI/SI/BC/DA/SA
Department
SQL
RDBMS
RDBMS
Figure 11. Departmental 2-Tier Design
Advantages
The advantages of the Departmental 2-Tier design option are the same as those
identified in design option 6.

Disadvantages
The disadvantages of the Departmental 2-Tier design option are the same as
those identified in design option 6.
Design Option 9–Departmental 2-Tier (Internal

Data Source)
The Departmental 2-Tier (Internal Data Source) design option is somewhat
opposite of design option 6 and does not reveal any additional information.

PUBLIC
INTERNET
PROXY
Internal Trust Zone
SQL
DTC (rpc ports)
RDBMS
RDBMS
SQL (1433)
DTC (rpc ports)
Firewall
SQL (1433)
Web Service SOAP - HTTP (80)/HTTPS (443) Load-Balanced

Client Cluster

Web Client
Figure 12. Departmental 2-Tier (Internal Data Source) Design

Advantages
The advantages of the Departmental 2-Tier (Internal Data Source) design option
are the same as those identified in design option 6.
Disadvantages
The disadvantages of the Departmental 2-Tier (Internal Data Source) design
option are the same as those identified in design option 6.
Design Option 10–Any Trust Zone to

External/Public Web Service
Going from a trust zone (perimeter, internal, or departmental) to a public Web
service requires the application (specifically, the Service Agent (SA) components)
to go through a proxy to access the public Internet. In addition, for a well secured
Web service, the application requires access to a certificate repository to use for
secure communications with the Web service.

PUBLIC
INTERNET
PROXY
Internal Trust Zone
SQL

DTC (rpc ports)
RDBMS
RDBMS
SQL (1433)
DTC (rpc ports)
Firewall
SQL (1433)
Web Service SOAP - HTTP (80)/HTTPS (443) Load-Balanced

Cluster
Client

Web Client
Figure 13. Any Trust Zone to External/Public Web Service Design
Advantage
The main advantage of the Any Trust Zone to External/Public Web Service design
option is that it allows monitoring and restriction of outbound traffic.
Disadvantage
The main disadvantage of the Any Trust Zone to External/Public Web Service
design option is that applications may be required to obtain credentials to pass
through the proxy (depending on the nature of the proxy).

Architecture Dependencies
The goal of an application infrastructure is to provide application services to its
users. The five defined architectures in WSSRA combine to provide an IT
environment that is suitable for mission-critical enterprise applications. The
application infrastructure architecture uses services provided by other
architectures, such as networking and management, to provide services that are
critical to the delivery of the application infrastructure architecture.
Service Dependencies
The following table lists the relationships between application infrastructure
architecture and the services upon which the architecture depends. It is possible
to implement an architecture without using all these services, although the
resulting architecture would be reduced in scope or scale accordingly.
Service Dependency Specific Requirements of the Service

.NET Framework Provides common language runtime and class
libraries for the .NET code
COM+ For COM components, and for .NET serviced
component hosting and security
Message Queuing For queued components, as well as general-purpose
asynchronous message queuing
Web Application Services For ASP.NET pages, hosting of the .NET remoted
components (other than the .NET serviced
components), hosting of Web Services
Data Services Application data and some application metadata
File Services Is needed at least for configuration files
(global.asax and Web.config, for example)
Networking Services Provides connectivity among tiers and between
clients and services
Certificate Services Uses authenticated identities, authorization,
certificates, and encryption
Infrastructure Management Services Instrumented to enable management of deployed
content and applications
Table 1. Application Infrastructure Architecture Service Dependencies
Standards and Guidelines

Applications use several standards pertaining to communication, data
representation, data storage and access, and even programming constructs such
as American National Standards Institute (ANSI) libraries. For details on how an
application uses these standards, refer to the “Web Application Services” and
• Networking standards (For more information, refer to the Network
Services Blueprint.)
• TCP/IP

• UDP/IP
• Web standards (For more information, refer to the Web Application
Services Blueprint.)
• HTTP/HTTPS
• XML
• SOAP/WSDL
• WSE (WS-Security, WS-Routing, WS-Coordination, and WS-
Transaction)
• RDBMS standards (For more information, refer to the Database Services
Blueprint.)
• SQL
Hardware Requirements
Some types of servers are better suited than others to perform specific tasks and
to host different products and technologies. Hardware requirements depend on
the specific usage model of each group of users, including Web customers,
application managers, and software engineers. For example, Web servers are
typically computers with good memory and processing power. However, they are
not required to have robust storage capabilities (such as redundant array of
independent disks (RAID) mirroring), because most of the data is stored in a
more robust fashion elsewhere. However, Web servers should be duplicated and
clustered to guard against server overload or potential failure of one server.
For more information on hardware requirements of individual application
components, refer to the following Service Blueprints:
Availability
Applications can be available only to the extent that their elements are available.
An application's availability can be improved by physically separating its critical
components from other computers and components that could fail. For example,
long running business processes can be implemented on an independent tier of
clustered servers so that a server failure in the Web farm does not prevent
business processes from being completed.
Application availability is difficult to measure because applications are typically
composed of numerous logical layers and can be deployed to multiple physical
tiers, sometimes with firewalls between them. For example, a simplistic measure
of Web site availability may be obtained by sending a simple HTTP request to the
Web site and acknowledging an appropriate response. However, this
request/response interaction will not exercise all elements of the application. A
better approach to measuring application availability is to independently “ping”
the layers/tiers of an application and wait for appropriate responses. However,
even this does not truly measure availability, because application failures often

arise out of the interaction between specific pieces of software. For example, a
given application component may respond correctly to a specific request
formulated by a test harness (used to drive application layers to measure
health), but it may not do so to a request sent by another layer of the application
itself because of issues such as software version mismatches, data conditions,
security context, and load factors.
For more information on how to make individual application services highly
available, refer to the following Service Blueprints:
Security
Security is one of the principal challenges of assembling distributed applications,
especially those that cross multiple physical tiers separated by firewalls.
Although security is discussed in depth in the Security Architecture Blueprint,
issues specific to application architecture are mentioned here.
Application infrastructure often implements security mechanisms in addition to
those provided by traditional infrastructure security components such as
firewalls, proxies, and virtual private network (VPN). Examples include
applications that restrict execution of code only to permitted clients, or to those
that encrypt the data that is passed to components. When designing applications
architects must take into consideration such items as the identity under which
their code will execute, the authentication method used to establish that identity
(if any), the necessary ports that need to be opened on any firewalls, and the
required services that will need to be running on both clients and servers.
The notion of security has many dimensions in the context of an application,
including:
• Identity authentication such as credential checking and certificate-based
non-repudiation.
• Restricted network traffic, including closing ports on firewalls and filtering
in proxies.
• Restricted access to data sources such as SQL Server.
• Restricted access to file system objects (that is, NTFS security).
• Maintaining data integrity through the use of secured channels and signed
messages.
• Maintaining data privacy through the use of secured channels, user access
through a virtual private network (VPN), and encrypted message passing.
The .NET Framework provides a code-based security model in which the privilege
to run a piece of code is based on the evidence its caller presents to the CLR.
This security model permits the application to restrict callers of a specific module
to those callers that present sufficient evidence (for example, digital signatures
loaded from a permissible location). The details of this security model are
provided in the Middleware Services Blueprint.

Security Design
Each application infrastructure design has unique security requirements that are
driven by the business requirements of the application, the characteristics of the
user audience, and the arrangement of boundaries that its applications need to
cross.
The physical location of users as well as business requirements that may for
instance restrict access to certain users or require some type of personalization
dictates to a great extent the authentication method as well as the application
type (such as Web, Windows®, or Web services). Authentication refers to the
process of ensuring that users are who they claim to be. There are various
methods of authenticating a user that depend upon the type of application and
how the user credentials will be managed. For example, an application may have
to provide the ability to audit user actions in which case the authentication
methods selected must provide a mean to track a user across all application
layers. On the other hand, applications without the audit requirement may
choose to authenticate a user at the presentation layer and then use a common
user (or users in the case of role-based systems) for all access to business and
data layers. Although the application level details may not be important for a
network architect or systems designer to understand, they will need to know
about any elements that depend upon the following:
• If the authentication method requires access to user credentials in Active
Directory® directory service then the application may need to be able to
access Active Directory using LDAP.
• Application architects may choose to implement some type of role based
security, in doing so they will consider various options some of which will
involve administrative tasks. For example, .NET role based security is
essentially a custom method but it often relies upon using users and
groups in Windows domains, Active Directory, or a custom scheme stored
in a database such as SQL Server. Architects may also opt to use the new
Authorization Manager included in the enterprise edition of Windows
Server 2003.
• Windows Access Control Lists (ACLs) can be used to create file system
permissions on specific application files for ASP.NET authorization. If
authorization will rely upon the use of ACLs then the appropriate
permissions will need to be identified and set. For more information about
ACLs see the following URL:
msdn.microsoft.com/library/en-s/security/security/access_control_lists.asp
• The ports that will need to be opened on any firewalls depending upon the
design of the applications.
• Specific runtime security policies that need to be set and distributed for
managed .NET code.
• The Windows services and features that an application needs to have
running. Computers should be configured in such a way as to reduce their
attack profile. This means that features and services that are not required
should either be disabled or removed. As a result, many applications will
begin to fail as they are migrated from development environments into
more secured environments such as test, staging, and ultimately

production unless system administrators are made aware of the required
dependent services.
Network architects and system designers on the other hand, need to inform
application architects of various items that may affect their security planning
such as:
• The existence of firewalls and status of trust relationships between
domains separated by firewalls.
• Limitations in the ports that will be allowed to be opened on firewalls.
• The existence of Group Policy restrictions. Administrators use Group Policy
to define specific Windows configurations and associate those
configurations to particular users and computers who are managed by
Active Directory. The application architects need to take these restrictions
into account while designing, developing and testing their applications.
Some examples of how boundaries affect security are provided in the following
list. Some of these boundaries can be removed through the consolidation of
multiple applications onto a single server.
• Process and AppDomain boundaries: The communication between
components residing in the same process or AppDomain boundary is
subject to the security facilities provided by .NET. When application
components must communicate across process (COM/.NET) or AppDomain
(.NET) boundaries, boundary security must be configured to enable this to
happen.
• Tier boundaries: The introduction of a tier boundary (that is, a server
boundary) between two adjacent application layers affects the security of
an application in the sense that applications must satisfy the remoting
security requirements.
• Layer boundaries: The introduction of a firewall between two adjacent
application layers affects the security of an application in numerous ways.
Most importantly, for security reasons a firewall may not be configured to
allow domain trust relationships to cross its boundaries. This means that
component remoting techniques do not operate using the default security
modes available on hand when a trust is available.
• Cluster boundaries: When an application layer runs on a tier that is
clustered, the security of the cluster should be configured in a way that is
appropriate for the security of the application.
• Consolidation on a single server: When multiple applications coexist
on a single server, other applications running on the server may be
operating at an inappropriate security level for the application. For
example, users of the other applications may not have authorization to
access the application in question. Care should be taken to ensure that all
applications running on the same server have the rights to operate within
the same security zone.
For additional information regarding the various authentication, authorization,
and secure communication mechanisms used by .NET connected applications
including ASP.NET, .NET Remoting, and Web services, see the online book
“Building Secure ASP.NET Applications: Authentication, Authorization, and Secure
Communication” at the following URL:

msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp?
frame=true&_r=1
For more information about Authorization Manager, refer to the following URL:
www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/entserver
/authm_topnode.asp
For more detailed information on security, refer to the Security Architecture
Blueprint. For detailed information on security issues related to .NET, refer to the
Security Lockdowns
Security lockdowns can be implemented through Group Policy, which provides
directory-based desktop configuration management. Group Policy may define
configurations for groups of users and computers. Settings may be specified for
registry-based policies, security, software installation, scripts, folder redirection,
and remote installation services using Group Policy.
Group Policy settings are contained in a Group Policy object (GPO), and can be
applied to users and computers by associating a GPO with the Active Directory
containers in which the users and computers reside. For example, an
organization may stipulate that application servers (running .NET Framework) will
not host Web services, and use Group Policy to disable the IIS service on those
servers.
In addition, several security lockdowns may be used among the various
application infrastructure elements in order to discourage casual deployment of
an application. These lockdowns must be overridden using management tools for
the various infrastructure elements required for successful deployment of an
application (such as IIS, .NET and COM+). For more information, refer to the Web
Application Services Blueprint and the Middleware Services Blueprint.
Scalability
The general approach to scalability is to partition the application into
architectural layers, which can be deployed to separate physical tiers that can be
scaled out independently. In practice, there is often a one-to-one relationship
between an application load at the point of entry into the application (for
example, the presentation layer) and the load at subsequent downstream layers
in the application for a given call path within it.
The entire architecture must be taken into account when identifying bottlenecks.
For example, even if the database server has the capacity to handle twice the
peak load, the entire system may be bottlenecked by some specific aspect of the
application, such as thread-contention or the network interface. By planning
ahead for scalability, it is possible to avoid such bottlenecks in the application.
For more information on scalability, refer to the relevant Service Blueprints:
• Web tier: Refer to the Web Application Services Blueprint.
• Application tier: Refer to the Middleware Services Blueprint.
• Data tier: Refer to the Data Services Blueprint.

Manageability
Manageability of an application is essential for ensuring its availability and
performance, and is crucially dependent on a number of factors, including:
• How well the services that host the application’s elements (such as COM+,
IIS, and .NET Framework) are instrumented to provide detailed information
about the application and granular control of the services.
• How well the application is instrumented to provide running information
on its health.
• How well an application’s layers are partitioned to enable granular
monitoring and control of the application.
• Availability of the management (operations) infrastructure.
The management infrastructure for applications must be designed in such a way
that it is not subject to misbehavior of the applications it is charged with
managing. The operations staff should be provided with information to allow
them to manage application health, comply with service level agreements (SLAs),
and scale up or out to manage capacity. For detailed guidelines on adding
instrumentation to applications, refer to the article titled Monitoring in .NET
Distributed Application Design on MSDN® at:
msdn.microsoft.com/library/en-us/dnbda/html/monitordotnet.asp?frame=true
For more information on how to manage individual application services, refer to
the following Service Blueprints:
For details on administration and operation of the application infrastructure
architecture, refer to the Infrastructure Management Services Blueprint.
Performance
The performance of an application is typically measured at the coarsest level by
the elapsed time for a representative request to be processed, which can be
measured from the client’s perspective or from the various points of entry in the
application’s layers on whatever tiers that are deployed. This measurement is
different from how efficiently an application processes a request with respect to
the resources it consumes, such as central processing unit (CPU), random access
memory (RAM), disk space, and network bandwidth.
Application performance can be improved by tuning the application design and
by scaling out with additional infrastructure. For further information, refer to the

Supportability
Supportability of an application depends on the diagnostic facilities provided by
the application infrastructure (.NET Framework or COM+, for example), and on
how well the application is engineered to provide support functions like error
handling and diagnostics capture. For additional information, refer to the
Consolidation
Application consolidation involves running portions of two or more applications
on a single tier, including tiers that are cloned among nodes in a load balanced
cluster. For example, assume that a typical Web application is deployed so that
its presentation layer runs on one tier (a load balanced cluster) running IIS, its
business layer runs on another tier (another load balanced cluster), and its
database runs on a third tier (a failover cluster). If the respective layers of a
separate yet similarly architected application were deployed on the same tiers, a
distinct set of challenges would arise from the infrastructure perspective,
including:
• Insulation of one application from the effects of another application.
• Accounting for resource use per application.
• Diagnosing problems (because the diagnostic practice cannot affect other
applications running on the same machines).
• Infrastructure change management. For example, if you change the
version of Microsoft ActiveX® Data Objects (ADO) for one application, you
have changed it for all, requiring more coordination among applications
for infrastructure changes. This can also include “application
infrastructure” in the form of application frameworks (for example, shared
or common class libraries).
Interoperability
Application interoperability consists of making programming calls to, and
accepting programming calls from, external systems. Web Services is the
emerging technique of choice, although several other techniques are widely
used, including:
• Electronic Data Interchange (EDI) for business-to-business
communications.
• SNA (LU6.2/APPC, LU2/3270, X/5250) for integration with older mainframe
applications.
• X.25 for facilitating WAN connectivity.
Regardless of the integration technology used, the challenges that must be
overcome include:

• Meshing the security models (for example, obtaining system-specific
credentials to pass to the external system).
• Configuring for conversion to and from external system data
representations (for example, EBCDIC and various numeric formats for
S/390, and big-endian/little-endian encoding), including those for
geographic and other locales (for example, code-pages on IBM systems).
• Configuring communication pathways such as TCP/IP, SNA network
protocols, and X.25.
• Resolving cross-platform issues such as diagnostics logging and alert
monitoring.
Using Microsoft Windows as an Integration

Environment
Although there are compelling reasons for moving rapidly and completely to the
Windows Server 2003 environment, some organizations may phase their
migration over time or limit their rollout to certain areas and services. Either way,
Windows Server 2003 needs to be integrated with the diverse systems,
applications, and platforms that make up their existing computing environment.
Microsoft offers a range of interoperability solutions that allows organizations to
benefit from the numerous advantages of the Windows Server 2003 environment
while protecting existing IT investments. Whether an organization's infrastructure
is UNIX-based, powered by IBM mainframes, or a Mac only zone, it is possible to
successfully integrate Windows Server 2003 and obtain the best of both worlds.
As a comprehensive interoperability solution for mixed computing environments,
Windows Server 2003 can:
• Communicate with other operating systems using common protocols. For
example, a Windows Server 2003 based server is able to communicate
with UNIX over local area networks (LANs) and the Internet.
• Access file shares and printers on other platforms. Windows Server 2003
provides services that allow file and print sharing on Macintosh systems. It
also supports the add on services that offer file and print sharing with
UNIX and IBM systems.
• Integrate new applications with data sources. Windows Server 2003
includes technologies that facilitate sharing of data and software code
between new and existing applications.
• Reduce the burden of administering multiple systems. For example,
organizations can use the Microsoft Active Directory service included with
Windows Server 2003 to unify and manage the multiple directories found
in most corporate networks.
In addition to the built in interoperability features of Windows Server 2003,
Microsoft offers additional services and products that help integrate Windows
Server 2003 with other systems. Services for UNIX 3.0 and Host Integration
Server help integrate Windows Server 2003 with UNIX and IBM-based systems,
respectively. In addition, Microsoft Windows Services for UNIX (incorporating the
Interix POSIX-compliant subsystem) makes it possible to run UNIX-based
applications and scripts on Windows Server 2003.

The following figure illustrates how Windows Server 2003 uses standards-based
protocol support and supplementary Microsoft products to provide
interoperability with non-Microsoft systems. The inner ring of the circle (in gray)
represents Windows Server 2003 standards-based protocol support. The outer
ring represents the various supplementary technologies that allow
Windows Server 2003 to interoperate with other platforms and services.
Examples of such supplementary technologies are listed outside the circle.
NetWare
File and Print Services for

NetWare
(Windows 2000 only)
Novell NDS,
Exchange,
Macintosh UNIX NIS,
IPX Active
Directory iPlanet,
Services Kerberos
TCP/IP Novell
for
Macintosh Groupwise,
PKI
Windows Server Metadirectory Lotus Notes
2003 Services
DHCP Built on LDAP
App
Interoperability
Services:
Standards OLE DB,
HTTP
Host ADO,
Integration DNS ODBC,
Server
XML
XML, SQL Server,
IBM, WBEM SOAP Oracle,
Amdahl, BizTalk Informix,
Hitachi IBM DB2
Services for XML/SOAP
Interix
UNIX
Web Services
Sun Solaris, HP/UX,

Linux, Tru64, IBM
Figure 14. A Schematic Representation of Windows Server 2003 Interoperability

As shown in the figure, the core of Windows Server 2003 interoperability is its
support for a number of common communications and security protocols,
including TCP/IP, Lightweight Directory Access Protocol (LDAP), Dynamic Host
Configuration Protocol (DHCP), the Domain Name System (DNS) protocol, and the
Kerberos Version 5 authentication protocol. With this support, Windows 2003
applications can communicate with:
• Operating systems such as Macintosh, HP-UX, Solaris, IBM AIX, and Linux.
• Directory-based services such as Novell NDS, Lotus Notes, Exchange, and
LDAP-based directories.
• Database platforms, such as those from IBM, Informix, and Oracle.

In addition to the extensive protocol support built into Windows Server 2003,
there are several technologies available from Microsoft that integrate
Windows Server 2003 with other operating systems. The following table lists the
major operating system platforms and identifies those areas where supplemental
Microsoft technologies provide interoperability for each of them.
Platform Network Data Applications

UNIX Services for UNIX Services for UNIX, Microsoft Interix
Microsoft Interix
IBM Host Integration Server Host Integration Server Host Integration Server
Macintosh Services for Macintosh Services for Macintosh N/A
Table 2. Platform Integration Technologies Available from Microsoft

In large organizations there is usually an established base of existing applications
running on various platforms, including IBM S/390 (MVS/IMS/CICS/DB2, and
VM/CMS/SQLDS), IBM AS/400, IBM S/36-38, and several UNIX variants.
Applications running on Windows Server 2003 would require integration with
applications running on these platforms. Microsoft Host Integration Server 2000
provides facilities for integrating systems at both the data level (by OLE/DB
providers) and the application level (by COMTI). It should be noted that
integration with applications and data on these platforms may involve use of
protocols other than TCP/IP, including IBM’s System Network Architecture (SNA)
protocols such as LU2 (3270) and LU6.2 (APPC/APPN). For more information on
network configuration and application, refer to the Host Integration Server 2000
documentation.
Interoperability–Web Services
Windows Server 2003 provides extensive support for using and hosting Web
services. Web Services Enhancements (WSE) provide routing, referral, inspection,
security, transactions, attachments, and other facilities to support the extended
capabilities necessary to make Web services viable in an enterprise. Windows
Server 2003 delivers a revolutionary application environment to build, deploy,
and run XML Web services, enabling applications to take advantage of the
loosely coupled principles of Internet computing.
Feature Description
Native XML Web Windows Server 2003 offers native support for XML Web service
Services Support standards, including XML, SOAP, Universal Description, Discovery, and
Integration (UDDI), and Web Services Description Language (WSDL).
Enterprise UDDI Windows Server 2003 includes Enterprise UDDI Services, a dynamic and
flexible infrastructure for XML Web services. This feature allows
companies to run their own internal UDDI service for intranets or
extranets. Developers can easily and quickly find and reuse the Web
services that are available within the organization, and IT administrators
can catalog and manage the programmable resources in their network.
With UDDI services, companies can build and deploy smarter, more
reliable applications.
Support for XML Web services are deeply integrated into Windows Server 2003;

Feature Description
Existing Services existing services like COM+ and Message Queuing can readily take
advantage of them. Administrators can allow existing COM+ applications
to be called using XML/SOAP by simply checking a configuration box.
Message Queuing can also use SOAP and XML to allow loosely coupled
applications to interoperate with a broad range of systems.
Federation XML Web services deliver the foundation and architecture for application
Infrastructure integration. Federation infrastructure is fundamentally about facilitating
servers and services to interoperate across trust boundaries.
Table 3. Web Service Features of Windows Server 2003
Previous Service Versions

All .NET applications can interoperate with applications written for previous
versions of the .NET Framework using the “side-by-side” capabilities of the .NET
Framework. In addition, .NET applications interoperate with COM-based
applications using .NET-COM interoperability. Details of this capability are
provided in the Middleware Services Blueprint. In addition, newly written .NET
applications can be integrated with previously written COM-based applications
through Web services protocols using IIS 6.0 capabilities to make COM
components available as Web services.
Localization
For details on localization of an application and the effects on application
infrastructure, refer to the following Service Blueprints:

CDC Design Considerations
This section focuses only on the Centralized Data Center (CDC) scenario. The
guidance provided here can be used as a part of any project that falls within the
same basic scope definitions outlined in the Introduction to Architecture
Blueprints.
Business Need
The application infrastructure architecture for an application that runs exclusively
inside a CDC scenario has the following unique characteristics:
• Largely trusted users.
• The possibility of using integrated security.
• A smaller subset of the security threats possible than when touching the
public Internet.
• A smaller set of users (typically).
• The ability to control client loads and ship client code to browser (for thin
clients).
• Potential inclusion of thick client applications, which implies software
distribution challenges.
As mentioned in the "Enterprise Design" section in this blueprint, the primary
concern for the application infrastructure architecture in a CDC scenario is to
provide a sound framework for the execution of mission-critical enterprise
applications.
Architecture Design
All the service definition options presented in the “Enterprise Design” section are
applicable in a CDC scenario. Design decisions include:
• Whether to adopt a 2-tier or 3-tier approach to application deployment.
• Whether the application is to be accessible externally or within the
organization.
• Whether the location of the data source is external or internal to the
organization.
Sample Applications
For the CDC scenario, the test labs implemented the following sample
applications in three representative architectural design variations:
• Fitch and Mather 7.0 (as distributed with VS.NET 2003)
• Nile 3.0

Architectural Design for Fitch and Mather 7.0
Detailed information about the architectural design of the Fitch and Mather 7.0
application are provided in its documentation, which is distributed with the
application.
At a high level, the application consists of a presentation layer, a business layer,
a data access layer, and a general accounting module (GAM). The three layers
are implemented exclusively in .NET (C#), while the GAM module is implemented
as a VC++ ATL component deployed in a COM+ application. In addition, there
are a number of utility classes used by multiple modules.
Application layers and subsystems are implemented as follows:
• The presentation layer is implemented as a number of ASP.NET pages
(.aspx) with corresponding code-behind files (.aspx.cs) in a single
assembly (FMStocks7.Web.dll).
• The business layer is implemented as a number of C# classes built into a
single assembly (FMStocks7.BLL.dll).
• The data access layer is implemented as a number of C# classes built into
a single assembly (FMStocks7.DAL.dll).
• The GAM is implemented as a COM server DLL (GAM.dll) and is deployed
to run in a COM+ application. A Runtime Callable Wrapper (RCW) for
GAM.dll is also provided (FMStocks7.GAM.dll).
• Utility classes are implemented in C# and built into a single assembly
(FMStocks7.Common.dll).
Architectural Design for Nile

The Nile .NET 3.0 sample application is a simple Web-based application designed
to test the ability of the underlying technical infrastructure to handle the load
placed on real world applications. It highlights how well an application server can
handle the rote tasks of database communication, dynamic page generation, and
transactions.
Nile is an online bookstore application meant to highlight the use of an
application server for product catalogs, ad-hoc product searches, product
browsing, customer account management, shopping carts, and order
transactions. Of the pages in the benchmark, 90 percent are dynamically
generated from the database content.
Technically, Nile is an ASP.NET/C# application that illustrates how a basic data-
driven Web application can work across SQL Server and Oracle databases. At a
high level, the Nile 3.0 application is a 2-tier architecture with presentation and
business layers running on the same server and the database running on a data
tier.
Application layers and subsystems are implemented as follows:
• The presentation layer is implemented as a number of ASP.NET pages
(.aspx), which use the Nile.dll written in C# to render data after reading it
from the back end SQL Server Nile database.
• The business layer is implemented as a number of C# classes built into a
single assembly (Nile.dll). The main class is NileProxy class, which consists

of all the methods called by the Nile .aspx Web pages. These methods
represent the middle tier business logic of the Nile application.
• The back end database is implemented on Microsoft SQL Server 2000. Nile
uses System.Data.SqlClient data classes, which provide data access to
SQL Server through a SQL Server provider written in managed .NET code
to boost the data access performance.
Logical Design
This section provides information about the logical design choices that were
made to deploy the three sample applications in the CDC scenario.
Application Architecture Design

Given that the CDC design implements two trust zones (Internal and Perimeter),
there are six design options described in the "Enterprise Design" section that are
applicable. These are:
1. Internal Only, 2-tier
2. Internal Only, 3-tier
3. External 2-tier (Data Source Internal)
4. External 3-tier (Data Source Internal)
5. External 3-tier (App and Data Source Internal)
6. Any Trust Zone to External/Public Web Service
For more information on advantages and disadvantages of these designs, refer to
the "Enterprise Design" section in this blueprint.
The labs chose to implement the three sample applications on three
representative architectural variations. The objective in choosing the
architectural variations was to select those designs that illustrated the most
significant infrastructure challenges, such as remoting and crossing firewalls.
• The first sample application, Fitch and Mather 7.0, is architecturally similar
to the canonical architecture pattern described in the "Enterprise Design"
section. It has clearly defined presentation, business, and data layers. In
addition, Fitch and Mather 7.0 uses serviced components to perform
transactional work. It also exercises the COM interoperability capabilities
of .NET.
• The Nile sample application is structurally simpler than Fitch and Mather
7.0. It does not have any serviced components or distributed transactions,
and does not exercise COM interoperability.
In the first variation, a decision was made to implement the Internal Only, 2-
tier design in the test labs because it represents a common architectural choice
for internal-only corporate applications. It is also possible to implement the
Internal Only, 3-tier design to verify complexities like component remoting by
following the steps provided in the second variation (External 3-tier (Data
Source Internal)).
This variation illustrates solutions for the following application architectural
challenges:

• Web tier (ASP.NET Web site) configuration
• App tier configuration
• Database access configuration

PUBLIC
INTERNET

PROXY
Internal Trust Zone
SOAP - HTTP (80)/HTTPS (443) HTTP (80)/HTTPS (443)

Load Balanced
Cluster
SQL (1433)
Internal SQL
RDBMS
RDBMS
Figure 15. First Design Variation (Internal Only, 2-Tier) for Sample Applications
In this variation, the presentation, business, and data layers of Nile 3.0 are
deployed to a load balanced clustered Web/App tier while the tables and stored
procedures are deployed to a failover clustered data tier.
In the second architectural variation, a decision was made to implement the
External 3-tier (Data Source Internal) design in the test labs. In addition to
what the previous variations provide, this variation illustrates solutions for the
following application architectural challenges:
• Component remoting within a domain
• Database access through a firewall
Recall that in the External 3-tier (Data Source Internal) design, the
presentation layer runs on the Web tier in the perimeter trust zone, the business
layer runs on the app tier in the perimeter trust zone, and the data source

resides in the internal trust zone. This could apply to a public-facing Web site or a
service that runs the presentation and business layers in the perimeter but needs
access to data kept on the internal network for security reasons.

Web Client PUBLIC
INTERNET

Web Service
Client
Firewall
PROXY

SOAP - HTTP (80)/HTTPS (443) SOAP - HTTP (80)/HTTPS (443)
Cluster Cluster

DTC (rpc ports) SQL (1433)
Firewall
Internal Trust Zone
SQL SQL (1433)
RDBMS
RDBMS
Figure 16. Second Design Variation (External, 3-Tier, Data Source Internal) for
Sample Applications
In this variation, the Fitch and Mather 7.0 sample application has its presentation
layer deployed to a load balanced clustered Web tier, the business layer
deployed to a load balanced clustered app tier, and the tables and stored
procedures deployed to a failover clustered data tier. The GAM module is also
deployed to the app tier.

Availability
Application infrastructure availability for a CDC scenario is equal to the
availability of individual service components that constitute the architecture. For
more details on service component availability, refer to the availability section in
the following Service Blueprints:
• Data Services Blueprint.
The availability requirements for application infrastructure architecture are
discussed in the "Enterprise Design" section in this blueprint. There are no
additional availability requirements for deploying applications in a CDC scenario.
Security
Application infrastructure security for a CDC scenario is dependent on the
security of the individual service components that constitute the architecture. For
more details on the security of service components, refer to the security section
in the following Service Blueprints:
• Database Services Blueprint
Security considerations for the application infrastructure architecture as a whole
were discussed in the "Enterprise Design" section in this blueprint. Overall
security architecture for the CDC scenario is described in the Security
Architecture Blueprint.
Security Lockdowns
Security lockdown requirements for application infrastructure architecture are
discussed in the "Enterprise Design" section earlier in this blueprint. There are no
additional security lockdown requirements for deploying application
infrastructure architecture in a CDC scenario.
Scalability
Application infrastructure scalability for a CDC scenario is based on the scalability
of individual service components that constitute the architecture. Details about
the scalability of the service components can be found in the scalability sections
of the individual Service Blueprints, which discuss different scaling options such
as scale up and scale out; they also contain information about different
technologies and parameters for scaling different services.

Manageability
Application infrastructure manageability for a CDC scenario is dependent on the
manageability of the individual service components that constitute the
architecture. Additional details about the manageability of the service
components can be found in the manageability section in the following Service
Blueprints:
The manageability requirements for application infrastructure architecture are
discussed in the "Enterprise Design" section in this blueprint. There are no
additional manageability requirements for deploying applications in a CDC
scenario.
Interoperability
Given that a CDC scenario could involve different kinds of interoperability, the
following design options are possible:
• Access to an external Web service.
• Publishing a Web service to an external client.
• Integration with existing systems.
• .NET/COM interoperability.
For more information on advantages and disadvantages of these design choices,
refer to the "Enterprise Design" section in this blueprint.
Service Dependencies
Application infrastructure service dependencies for the CDC scenario are the
same as those discussed previously in the "Enterprise Design" section in this
blueprint, namely:
• Middleware Services (.NET Framework, COM+, and Message Queuing)
• Web Application Services
• Data Services
• File Services
• Network Services
• Certificate Services
• Infrastructure Management Services

SBO Design Considerations
In a satellite branch office that relies on centralized services from a centralized or
regional data center, there are no server based applications that need to be
hosted. The branch offices run clients that access the corporate applications
across the WAN links by a VPN connection.
Architecture Design
There is no application infrastructure architecture in a branch office that uses
centralized services from a centralized or regional data center.

Summary
This blueprint has provided detailed insights into the types of design options and
choices faced by an Enterprise Architect when designing an infrastructure that is
capable of supporting application requirements in an enterprise-class
organization. The advantage of this guidance is that it has been implemented
and tested in the test labs.

References
This section provides links to additional background information on the following
related subjects:
Application Architecture
• A discussion of design principles for multi-tier applications with particular
relevance to Windows Server 2003:
msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch001.asp
• Patterns and practices: Microsoft's recommendations for architects,
software developers, and IT professionals responsible for delivering and
managing enterprise systems on the Microsoft platform.
msdn.microsoft.com/practices/
• "Application Architecture for .NET: Designing Applications and Services"
msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp
• “Microsoft's Application Server: Windows Server 2003,” Directions on
Microsoft, December 2002 edition:
www.directionsonmicrosoft.com/
COM
• "Microsoft Component Services"
COM+
• COM+ 1.5 features:
msdn.microsoft.com/msdnmag/issues/01/08/ComXP/ComXP.asp
• Preliminary Platform SDK documentation for new features in COM+ 1.5:
msdn.microsoft.com/library/en-us/cossdk/htm/whatsnewcomplus_350z.asp
• COM+ partitions:
msdn.microsoft.com/library/en-
us/cossdk/htm/pgservices_partitions_1gdb.asp
• "Configuring Microsoft Distributed Transaction Coordinator (MSDTC) to
Work Through a Firewall"
support.microsoft.com/default.aspx?scid=KB;EN-US;q250367and
Message Queuing
• "About Message Queuing"
msdn.microsoft.com/library/en-us/msmq/msmq_about_intro_25bb.asp

.NET
• Information on .NET application domains:
msdn.microsoft.com/library/en-
us/cpguide/html/cpconapplicationdomains.asp
• Web Services Transaction:
msdn.microsoft.com/library/en-us/dnglobspec/html/ws-transaction.asp

Application Infrastructure Architecture

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Application Infrastructure Architecture

Uploaded by

Copyright:

Available Formats

Windows Server System

Published: March 2005

Who Should Read This Blueprint

Application Infrastructure Architecture Blueprint 1

2Windows Server System Reference Architecture

Application Infrastructure Architecture Blueprint 3

Servers Storage Devices Hardware

Figure 1. Components of an Enterprise Application

Application Infrastructure Architecture Concepts

4Windows Server System Reference Architecture

Application Infrastructure Architecture Blueprint 5

Data Access Logic

Data Sources Services

Figure 2. Application Layers and Physical Tiers

6Windows Server System Reference Architecture

Application Infrastructure Architecture Blueprint 7

What Applications Need and How Infrastructure

8Windows Server System Reference Architecture

Application Infrastructure Architecture Blueprint 9

Application Deployment Considerations

10Windows Server System Reference Architecture

Application Infrastructure Architecture Blueprint 11

Application Client Types

12Windows Server System Reference Architecture

Web Service Clients

Application Infrastructure Architecture Blueprint 13

Application Infrastructure for the Development

14Windows Server System Reference Architecture

Application Infrastructure Architecture Blueprint 15

DevelopmentManages Test/QualityAssurance InfrastructureManages

Figure 3. Application Deployment Environments

16Windows Server System Reference Architecture

Design Option 1–Internal Only, 2-Tier

Application Infrastructure Architecture Blueprint 17

SOAP - HTTP (80)/HTTPS (443)

Internal Trust Zone

Thick Client Web Client

SOAP - HTTP (80)/HTTPS (443) HTTP (80)/HTTPS (443)

Figure 4. Internal Only, 2-Tier Design

18Windows Server System Reference Architecture

SOAP - HTTP (80)/HTTPS (443)

Internal Trust Zone

Thick Client Web Client

SOAP - HTTP (80)/HTTPS (443)

Load Balanced Load Balanced

.NET Remoting HTTP(80)

Figure 5. Internal Only, 3-Tier Design

Application Infrastructure Architecture Blueprint 19

Design Option 3–External 2-Tier (Data Source

20Windows Server System Reference Architecture

HTTP (80)/HTTPS (443)

SOAP - HTTP (80)/HTTPS (443)

Perimeter Trust Zone

DTC (rpc ports)

Figure 6. External 2-Tier (Data Source Internal) Design

Application Infrastructure Architecture Blueprint 21

Design Option 4–External 3-Tier (Data Source

HTTP (80)/HTTPS (443) SOAP - HTTP (80)/HTTPS (443)

HTTP (80)/HTTPS (443) SOAP - HTTP (80)/HTTPS (443)

Perimeter Trust Zone

.NET Remoting HTTP(80)

SQL Internal SQL

Figure 7. External 3-Tier (Data Source Internal) Design