Fast Track: A Guide for Getting Started and Applying the Guidance

J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat

Objectives

  • Understand the key components of this guide.
  • Learn about the canonical layered application style.
  • Learn the steps you should follow when beginning your design.
  • Learn about the main application types and architectural styles.
  • Learn the quality attributes and understand the engineering hotspots that are important when designing an application.

Overview

This “fast track” chapter highlights the basic approach taken by this guide to help you design and architect layered applications across a variety of application types and architecture styles. Use this chapter to understand the basic approach, application types, architecture styles, the quality attributes that impact application design, and the key engineering decisions to consider when designing application architecture.

Architecture Meta-frame

The architecture meta-frame can help you to focus on the key factors that can influence your design. Use the meta-frame to formulate how you will design your architecture, to help you ask key questions when reviewing your architecture, and as a way to organize your thoughts during design activities. This guide is organized around the application types, architecture styles, and architecture frame described by this architecture meta-frame.

ArchMetaFrame.PNG
Figure 1 The architecture meta-frame

The meta-frame contains the following key components:
  • Scenarios.** Application scenarios tie architecture solutions to the real-world scenarios that impact your application design. For example, your application may map to an Internet Web application scenario, which has unique architecture solutions compared to a mobile client application.
  • Quality attributes. Quality attributes represent cross-cutting concerns that apply across application types, and should be considered regardless of architecture style. Security, performance, maintainability, and reusability are examples of quality attributes.
  • Requirements and constraints. Requirements and constraints narrow the range of possible solutions for your application architecture problems.
  • Application types. Application types categorize the major application technology stacks on the Microsoft platform. Examples of application types include mobile, rich Internet application (RIA), services application, and Web application.
  • Architecture styles. An architectural style is a collection of principles that shapes the design of your application. Many of these styles overlap and can be used in combination. Architectural styles tend to be tied both to the application type and to the point in time in which the application was developed.
  • Architecture frame. The architecture frame is a collection of hotspots that you can use to analyze your application architecture. This helps you to turn core features such as caching, data access, validation, and workflow into actions.

Reference Application Architecture

The reference application architecture represents a canonical view of a typical application architecture, using a layered style to separate functional areas into separate layers. The reference application architecture demonstrates how a typical application might interact with its users, external systems, data sources, and services. The reference application architecture also shows how cross-cutting concerns such as security and communication impact all of the layers in your design, and must be designed with the entire application in mind.

RefAppArch.PNG
Figure 2 The reference application architecture

Presentation Layer Components

  • User interface (UI) components. UI components provide a way for users to interact with the application. They render and format data for users and acquire and validate data input by the user.
  • User process components. To help synchronize and orchestrate these user interactions, it can be useful to drive the process by using separate user process components. This means that the process-flow and state-management logic is not hard-coded in the UI elements themselves, and the same basic user interaction patterns can be reused by multiple UIs.

Service Layer Components

  • Service interfaces. Services expose a service interface to which all inbound messages are sent. The definition of the set of messages that must be exchanged with a service, in order for the service to perform a specific business task, constitutes a contract. You can think of a service interface as a façade that exposes the business logic implemented in the service to potential consumers.
  • Message types. When exchanging data across the service layer, data structures are wrapped by message structures that support different types of operations. For example, you might have a Command message, a Document message, or another type of message. These message types are the “message contracts” for communication between service consumers and providers.

Business Layer Components

  • Application facade (optional). Use a façade to combine multiple business operations into a single message-based operation. You might access the application façade from the presentation layer by using different communication technologies.
  • Business components. Business components implement the business logic of the application. Regardless of whether a business process consists of a single step or an orchestrated workflow, your application will probably require components that implement business rules and perform business tasks.
  • Business entity components. Business entities are used to pass data between components. The data represents real-world business entities, such as products and orders. The business entities used internally in the application are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented by using custom object-oriented classes that represent the real-world entities your application has to work with, such as a product or an order.
  • Business workflows. Many business processes involve multiple steps that must be performed in the correct order and orchestrated. Business workflows define and coordinate long-running, multi-step business processes, and can be implemented using business process management tools.

Data Layer Components

  • Data access logic components. Data access components abstract the logic necessary to access your underlying data stores. Doing so centralizes data access functionality, and makes the process easier to configure and maintain.
  • Data helpers / utility components. Helper functions and utilities assist in data manipulation, data transformation, and data access within the layer. They consist of specialized libraries and/or custom routines especially designed to maximize data access performance and reduce the development requirements of the logic components and the service agent parts of the layer.
  • Service agents. Service agents isolate your application from the idiosyncrasies of calling diverse services from your application, and can provide additional services such as basic mapping between the format of the data exposed by the service and the format your application requires.

Designing Your Architecture

The approach to architectural design can be divided into the following steps:

ArchDesignProcess.PNG
Figure 3 Core architecture design activities

These steps are:
  • Step 1: Identify Architecture Objectives. Clear objectives help you to focus on your architecture, and on solving the right problems in your design. Good objectives help you to determine when you are finished with the current phase, and when you are ready to move on to the next phase.
  • Step 2: Key Scenarios. Use key scenarios to focus your design on what matters most, and to evaluate your candidate architectures when they are ready.
  • Step 3: Application Overview. Understand your application type, deployment architecture, architectural styles, and technologies in order to connect your design to the real world in which the application will have to operate.
  • Step 4: Key Hotspots. Identify key hotspots based on quality attributes and the architecture frame. These are the areas where mistakes are most often made when designing an application.
  • Step 5: Candidate Solutions. Create a candidate architecture or architectural spike and evaluate it against your key scenarios, hotspots, and deployment constraints.

This approach will allow you to design a candidate architecture that can be reviewed, tested, and compared to your requirements and constraints. You can iteratively flesh out your architecture as you work through your design and discover more details that impact your architecture. You do not have to build your architecture in a single iteration. Don’t get lost in the details; focus on the big steps and build a framework on which you can base your architecture and design.

Application Types

Your choice of application type will be related both to the technology constraints and the type of user experience you plan to deliver. Use scenarios to help you choose an application type. For example, if you want to support rich media and graphics delivered over the Internet, a rich Internet application (RIA) is probably the best choice. However, if you want to support data entry with forms in an occasionally connected scenario, a rich client is probably the best choice. Use the table below to review and understand each application type.

Table 1 Application types
Application type Description
Mobile Application Can be developed as a Web application or a rich client application.
Can support occasionally connected scenarios.
Runs on devices with limited hardware resources.
Rich Client Application Usually developed as a stand-alone application.
Can support disconnected or occasionally connected scenarios.
Uses the processing and storage resources of the local machine.
Rich Internet Application Can support multiple platforms and browsers.
Can be deployed over the Internet.
Designed for rich media and graphical content.
Runs in the browser sandbox for maximum security.
Can use the processing and storage resources of the local machine.
Service Application Designed to support loose coupling between distributed components.
Service operations are called using XML-based messages.
Can be accessed from the local machine or remotely, depending on the transport protocol.
Web Application Can support multiple platforms and browsers.
Supports only connected scenarios.
Uses the processing and storage resources of the server.

Architectural Styles

Your choice of architectural styles will depend upon your application type, the requirements and constraints of your application, the scenarios you want to support, and—to some extent—the styles with which you are most familiar and comfortable. Your choice of architectural styles represents a set of principles that your design will follow—an organizing set of ideas that you can use to keep your design cohesive and focused on your key objectives and scenarios. Use the table below to review and understand the key set of architectural styles.

Table 2 Architectural styles
Architecture style Description
Client-Server Segregates the system into two computer programs where one program, the client, makes a service request to another program, the server.
Component-Based Architecture Decomposes application design into reusable functional or logical components that are location-transparent and expose well-defined communication interfaces.
Layered Architecture Partitions the concerns of the application into stacked groups (layers).
Message-Bus A software system that can receive and send messages that are based on a set of known formats, so that systems can communicate with each other without needing to know the actual recipient.
N-tier / 3-tier Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.
Object-Oriented An architectural style based on division of tasks for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object.
Separated Presentation Separates the logic for managing user interaction from the UI view and from the data with which the user works.
Service-Oriented Architecture (SOA) Refers to applications that expose and consume functionality as a service using contracts and messages.

Quality Attributes

Use the quality attributes to focus your thinking around critical problems that your design should solve. Addressing quality attributes in your design rather than during development will improve the likelihood that your application will be successful in the long term. Use the table below to review and understand each quality attribute.

Table 3 Quality attributes
Category Description
Availability Availability defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period. Availability will be affected by system errors, infrastructure problems, malicious attacks, and system load.
Conceptual Integrity Conceptual integrity defines the consistency and coherence of the overall design. This includes the way that components or modules are designed, as well as factors such as coding style and variable naming.
Flexibility Flexibility is the ability of a system to adapt to varying environments and situations, and to cope with changes to business policies and rules. A flexible system is one that is easy to reconfigure or adapt in response to different user and system requirements.
Interoperability Interoperability is the ability of diverse components of a system or different systems to operate successfully by exchanging information, often by using services. An interoperable system makes it easier to exchange and reuse information internally as well as externally.
Maintainability Maintainability is the ability of a system to undergo changes to its components, services, features, and interfaces as may be required when adding or changing the functionality, fixing errors, and meeting new business requirements.
Manageability Manageability defines how easy it is to manage the application, usually through sufficient and useful instrumentation exposed for use in monitoring systems and for debugging and performance tuning.
Performance Performance is an indication of the responsiveness of a system to execute any action within a given interval of time. It can be measured in terms of latency or throughput. Latency is the time taken to respond to any event. Throughput is the number of events that take place within given amount of time.
Reliability Reliability is the ability of a system to remain operational over time. Reliability is measured as the probability that a system will not fail to perform its intended functions over a specified interval of time.
Reusability Reusability defines the capability for components and subsystems to be suitable for use in other applications and in other scenarios. Reusability minimizes the duplication of components and also the implementation time.
Scalability Scalability is the ability of a system to function well when there are changes to the load or demand. Typically, the system will be able to be extended by scaling up the performance of the server, or by scaling out to multiple servers as demand and load increase.
Security Security defines the ways that a system is protected from disclosure or loss of information, and the possibility of a successful malicious attack. A secure system aims to protect assets and prevent unauthorized modification of information.
Supportability Supportability defines how easy it is for operators, developers, and users to understand and use the application, and how easy it is to resolve errors when the system fails to work correctly.
Testability Testability is a measure of how easy it is to create test criteria for the system and its components, and to execute these tests in order to determine if the criteria are met. Good testability makes it more likely that faults in a system can be isolated in a timely and effective manner.
Usability Usability defines how well the application meets the requirements of the user and consumer by being intuitive, easy to localize and globalize, able to provide good access for disabled users, and able to provide a good overall user experience.

Architecture Frame

The architecture frame is a collection of hotspots that represent key engineering decisions. Each represents an opportunity to improve your design and build a technically more effective architecture. This architecture frame is part of the larger architecture meta-frame, and is used throughout the guide to organize key patterns, principles and practices. These categories help you to focus on the most important areas, and obtain the most meaningful and actionable guidance.

Categories

Use the table below to review and understand each category in the architecture frame.

Table 4 Architecture frame categories
Category Description
Authentication and Authorization Authentication and authorization allow you to identify the users of your application with confidence, and to determine the resources and operations to which they should have access.
Caching and State Caching improves performance, reduces server round trips, and can be used to maintain the state of your application.
Communication Communication strategies determine how you will communicate between layers and tiers, including protocol, security, and communication-style decisions.
Composition Composition strategies determine how you manage component dependencies and the interactions between components.
Concurrency and Transactions Concurrency is concerned with the way that your application handles conflicts caused by multiple users creating, reading, updating, and deleting data at the same time. Transactions are used for important multi-step operations in order to treat them as though they were atomic, and to recover in the case of a failure or error.
Configuration Management Configuration management defines how you configure your application after deployment, where you store configuration data, and how you protect the configuration data.
Coupling and Cohesion Coupling and cohesion are strategies concerned with layering, separating application components and layers, and organizing your application trust and functionality boundaries.
Data Access Data access strategies describe techniques for abstracting and accessing data in your data store. This includes data entity design, error management, and managing database connections.
Exception Management Exception-management strategies describe techniques for handling errors, logging errors for auditing purposes, and notifying users of error conditions.
Logging and Instrumentation Logging and instrumentation represents the strategies for logging key business events, security actions, and provision of an audit trail in the case of an attack or failure.
User Experience User experience is the interaction between your users and your application. A good user experience can improve the efficiency and effectiveness of the application, while a poor user experience may deter users from using an otherwise well-designed application.
Validation Validation is the means by which your application checks and verifies input from all sources before trusting and processing it. A good input and data-validation strategy takes into account not only the source of the data, but also how the data will be used, when determining how to validate it.
Workflow Workflow is a system-assisted process that is divided into a series of execution steps, events, and conditions. The workflow may be an orchestration between a set of components and systems, or it may include human collaboration.

Key Engineering Decisions

Use the architecture frame as a way to organize and think about key engineering decisions. The following table shows key engineering decisions for each category in the architecture frame.

Table 5 Key engineering decisions
Category Key problems
Authentication and Authorization How to store user identities
How to authenticate callers
How to authorize callers
How to flow identity across layers and tiers
Caching and State How to choose effective caching strategies
How to improve performance by using caching
How to improve availability by using caching
How to keep cached data up to date
How to determine the data to cache
How to determine where to cache the data
How to determine an expiration policy and scavenging mechanism
How to load the cache data
How to synchronize caches across a Web or application farm
Communication How to communicate between layers and tiers
How to perform asynchronous communication
How to communicate sensitive data
Composition How to design for composition
How to design loose coupling between modules
How to handle dependencies in a loosely coupled way
Concurrency and Transactions How to handle concurrency between threads
How to choose between optimistic and pessimistic concurrency
How to handle distributed transactions
How to handle long-running transactions
How to determine appropriate transaction isolation levels
How to determine whether compensating transactions are required
Configuration Management How to determine the information that must be configurable
How to determine location and techniques for storing configuration information
How to handle sensitive configuration information
How to handle configuration information in a farm or cluster
Coupling and Cohesion How to separate concerns
How to structure the application
How to choose an appropriate layering strategy
How to establish boundaries
Data Access How to manage database connections
How to handle exceptions
How to improve performance
How to improve manageability
How to handle binary large objects (BLOBs)
How to page records
How to perform transactions
Exception Management How to handle exceptions
How to log exceptions
Logging and Instrumentation How to determine the information to log
How to make logging configurable
User Experience How to improve task efficiency and effectiveness
How to improve responsiveness
How to improve user empowerment
How to improve the look and feel
Validation How to determine location and techniques for validation
How to validate for length, range, format, and type
How to constrain and reject input
How to sanitize output
Workflow How to handle concurrency issues within a workflow
How to handle task failure within a workflow
How to orchestrate processes within a workflow

Last edited Jan 13, 2009 at 12:21 AM by prashantbansode, version 5

Comments

No comments yet.