Note that the information on this page is the BETA 1 of a guide that is now released. See
http://www.codeplex.com/AppArchGuide for the latest PDF and HTML content.
Architecture and Design Best Practices at a Glance
- J.D. Meier, Alex Homer, David Hill,
Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
This chapter presents a wide-ranging overview of the key factors involved in designing the architecture for your applications. It describes the general steps in the process, the types of application you can build, the typical layered architecture for your applications,
and the design approaches for data access, services, and quality attributes.
- Learn about the typical general approach to designing application architectures.
- Learn about the different types of applications that you can build.
- Learn about the key factors you must consider when designing application architectures.
- Learn about the layered approach to application design.
- Learn about the quality attributes that affect the overall success and acceptance of an application.
The following guidelines will help you to understand the typical features of the design process.
- How to design your architecture
Choose the application type that is applicable to your scenario and requirements. Identify common patterns used to represent application structure such as client/server and n-tier. Consider deployment scenarios for the application; understand your physical
deployment in order to put your architecture in perspective and make the appropriate tradeoffs. Understand security requirements for the environment in which your application will be deployed. For example, many security policies require physical separation
of presentation logic from business logic across different sub-nets. Consider scalability and reliability requirements for your application and how these will impact your overall architecture.
- How to structure your application
Start at the highest level of abstraction and begin by grouping your application functionality into logical layers. Next, look at how your application will be deployed; understand the physical structure of the machines and tiers. Then determine which layers
should be logically grouped in each physical tier. Define the public interface for each layer, the information that will be communicated between layers, and the form of that communication. Finally, determine the communication protocols that will be used for
communication between the layers and tiers in your application.
- How to choose a deployment topology
Consider corporate policies and procedures, as well as the infrastructure to which you plan to deploy. If the target environment is rigid, your application design must reflect the constraints that exist in this environment. Do not design for the ideal environment,
but rather for the real environment in which you know you will deploy the application. Take into account Quality of Service (QoS) requirements such as security and maintainability. Understand protocol restrictions and network topologies, as these are likely
to force tradeoffs in your design. In general, aim to locate all of the application on the same server, because each physical boundary crossing degrades performance due to data serialization. If you are developing a client that will access an application server,
or a stand-alone client that will access an external database, consider a client/server topology. If you are developing an intranet application or an Internet application in which the business logic can be on a public-facing server, consider a three-tier topology.
If you are building an Internet-facing application in which the business logic must remain behind the firewall, or an application in which you need to locate application components on separate servers for scalability or performance reasons, consider an n-tier
- How to decide on your layering strategy
Layering is used for structuring and decomposing systems; it logically partitions the system into set of related components, and provides a way to achieve loose coupling. Typically, applications use presentation, business, data access, and service layers. When
grouping the components in a layer, make sure those components depend only on the components in the same layer or in a lower layer. Avoid any circular dependencies. Use only the layers that are required, and are relevant to your scenario. If your application
does not have a user interface, you will not require a presentation layer. If your application does not require business logic; for example, a reporting application, you may not require a business layer. If your business logic is not shared by other applications,
or is not located on remote tier, you may not require a service layer. If your application does not use an external data source, you may not require a data access layer.
- How to choose your interfaces
Use loose coupling between layers; do not expose internal components that another layer could become dependent upon and break when those internal details change. Use public interfaces to define ‘contracts’ for interaction with the layer, and to hide internal
details. If you want to implement different behavior with concrete instances of the interface, consider using an abstract interface. If you want a fast and easy way to implement the interface for your layer, consider using a common design type. If you want
to provide maximum testability, consider using the dependency inversion pattern. If your application must support multiple client types or interaction across physical and process boundaries, consider using a message-based interface.
- How to design for user experience
Discover and follow published user interface guidelines. There are platform-level best practices and guidelines for each UI technology, and in many cases an organization will have published guidelines that you should adhere to. Use composite patterns for the
look and feel of your application. Use controller patterns such as MVC, Supervising Controller, and Passive View to design the UI processing for your application. Design the interface so that each page or section is focused on a specific task. Consider dividing
large pages/screens with excessive functionality into smaller pages/screens. Design similar components to have consistent behavior across the application. For example, a grid used to display data should implement a consistent interface for paging and sorting
- How to design for composition
Design your user interface components in a structured way to provide a consistent look and feel for your application. Provide a consistent interface to avoid confusing users as they navigate through your application. Consider using templates, such as a master
page in ASP.NET, or implement one of many common design patterns. Avoid using dynamic layouts, as they can be difficult to load and maintain. Be careful with dependencies between components. Use abstraction patterns when possible to avoid issues with maintainability.
Use well-known design patterns to implement a composite interface containing separate modules or user controls where appropriate. Consider creating templates with placeholders. For example, use the Template View pattern to compose dynamic Web pages to ensure
reuse and consistency. Consider composing views from reusable modular parts. For example, use the Composite View pattern to build a view from modular, atomic component parts.
- How to perform architecture and design reviews
Establish design and coding standards that developers on the team should follow. Review the design of your application in relation to your target deployment, infrastructure constraints, and pre-defined performance and security goals. Use design inspections
to evaluate the design against the architecture frame, using a question driven approach to focus your efforts.
The following guidelines will help you to understand the fundamentals of choosing an application type, and learn the capabilities and design fundamentals of each type.
- How to choose an application type
The decision on a choice of application type is governed by various factors such as the business problem, end user requirements, and organizational constraints. If the majority of your users have handheld devices, your application does not require a complex
UI, and you must support offline or occasionally connected scenarios, consider building a mobile application. If your users work with standard PCs and require a highly interactive and responsive application, you want to use the resources of the client computer,
and you must support offline or occasionally connected scenarios, consider building a rich client. If you want to deploy your application over the Internet, you want to support a rich interactive and responsive UI, and you want to use client-side processing,
consider building a Rich Internet Application (RIA). If your application must expose functionality to clients in a loosely coupled way, especially if the application will be shared or consumed by other applications over the Internet or intranet, consider building
a service. If you do not require a rich interactive UI, you want to deploy over the Internet, and you want to maximize platform and browser independence, consider building a Web application.
- How to design a mobile application
Applications for mobile devices fall into two categories: Web applications and rich client applications. The decision on the type of application you design can be based on the connection requirements, resource requirements, and UI requirements. If your users
do not need to work disconnected, and your performance requirements can be met with regard to the network bandwidth constraints of your users, consider a Web-based mobile client. Another option for a connected scenario, where a rich interface is required,
is a Rich Internet Application. If your users must work in a disconnected or occasionally connected way, or if you require direct access to the device hardware resources, consider a mobile rich client. Consider screen size and format, CPU performance characteristics,
memory and storage space, development tool and environment support, as well as user requirements and organizational constraints, when choosing which device types to support. Mobile devices require a simpler architecture, simpler UI, and other design decisions
to work within the constraints imposed by the device hardware. Keep these constraints in mind and design specifically for the device instead of trying to reuse the architecture or UI from a desktop application or a Web application. Every design decision should
take into account the limited CPU, memory, storage and battery life of mobile devices. In addition, most mobile applications must work when a network connection is intermittent or not available. Design your caching, state management, and data access mechanisms
with intermittent network connectivity in mind.
- How to design a rich client application
Rich client applications offer complex data visualization, superb text flow content rendering, access to local resources and devices, and a rich and dynamic interactive experience. Rich Client applications range from thin interfaces that overlay business layers
and service layers, to complex applications that perform most of the processes themselves and just communicate with other layers to consume or send back information. Various technologies are available to design rich client applications. These technologies
include Windows Forms, Windows Presentation Foundation (WPF), XAML Browser Applications (XBAP), and Office Business Applications (OBA). A typical rich client application design focuses on the separation of UI from processing, on the user interface, on the
handling of business rules, and on communication between layers. Separate the presentation logic from the interface implementation using design patterns such as MVC and Supervising Controller. Separating UI rendering from UI processing eases maintenance, promotes
reusability, and improves testability. Design to provide a suitable and usable interface. Take into account features such as layout, navigation, choice of controls, and localization to maximize accessibility and usability. Extract business rules and other
tasks not related to the user interface. A separate business layer should handle tasks not directly related to presentation, or related to collecting and handling user input. Loosely couple your client to any remote services it uses. Use a message-based interface
to communicate with services on separate physical tiers. Avoid tight coupling to objects in other layers. Use the abstraction provided by common interface definitions, abstract base classes, or messaging when communicating to other layers of the application.
For example, implementing the Dependency Injection and Inversion of Control patterns can provide a shared abstraction between layers.
Rich Internet Applications offer the benefits of distributed, server-based Internet applications combined with the rich interface and interaction capabilities of desktop applications. A Microsoft RIA implementation using Silverlight includes all of these benefits,
plus the ability to interact with and manipulate data, rather than simply visualize or present it. A typical RIA design focuses on the UI, including layout, responsiveness and usability, security and infrastructure, and related features. When designing a RIA,
consider using a single page that changes dynamically as the user works with the application. Multipage designs are more complex in a RIA, and require additional considerations such as deep linking and UI screen navigation. For multi-step process, consider
using a workflow to drive the process. Users should be able to easily navigate or pause, and return to the appropriate point in the workflow without restarting the whole process. Plan to use a Web-based infrastructure, because RIA implementations require a
similar infrastructure to Web applications. Design your application to run in the browser sandbox. RIA implementations have higher security by default, and so may not have access to all devices on a machine. , Consider scenarios in which the browser plug-in
is not already installed; design for non-interruptive installation, including displaying informative error messages if an installation problem should occur.
- How to design a service application
The key benefit of Service applications is that they allow customers to relinquish control over software versions or changing requirements to the server or hosting organization that exposes the service. A typical service application design focuses on features
such as performance, security, and compatibility. Design the service to be autonomous; do not make assumptions about the client and how they plan to use the services you expose. Design only for the service contract; do not implement functionality that is not
reflected by the contract. Design operations to be coarse-grained; avoid chatty calls to the service, which can lead to very poor performance. Instead, use the Façade pattern to package smaller fine-grained operations into single coarse-grained operations.
Design for extensibility; data contracts should be designed so that you can extend them without affecting consumers of the service. When possible, use standard elements to compose the complex types used by your service. Design for compatibility based on policy;
the service should publish a policy that describes how consumers can interact with the service. This is more important for public services, where consumers can examine the policy to determine interaction requirements.
- How to design a Web application
A typical Web application design focuses on features such as layering, security and performance. Use layering to partition your application components logically into presentation, business, and data access layers. This helps you to create maintainable, scalable
code and allows you to monitor and optimize the performance of each layer separately. Use abstraction to implement loose coupling between layers. This can be accomplished by defining interface components, such as a façade with well-known inputs and outputs
that translates requests into a format understood by components within the layer. In addition, you can use interface types or abstract base classes to define a shared abstraction that must be implemented by interface components. When designing a Web application,
consider using techniques such as caching and output buffering to reduce round trips between the browser and the Web server, and between the Web server and downstream servers. Avoid blocking during long-running tasks. If you have long-running or blocking operations,
consider using an asynchronous approach to allow the Web server to process other incoming requests. Design your application to authenticate users whenever they cross a trust boundary; for example, when accessing a remote business layer from your presentation
layer. Consider using a trusted sub-system for authentication across trust boundaries. This is particularly useful when accessing a data layer that connects to a database. When using a trusted sub-system, consider flowing the user’s identity with the call
in order to support auditing and non-repudiation. Whenever you must pass sensitive data such as a password or authentication cookie across the network, consider encrypting and signing the data or using a secure transport mechanism such as SSL. Design to run
your Web application using a least-privilege account. If an attacker manages to take control of a process, the process identity should have restricted access to the file system and other system resources in order to limit the possible damage.
The following guidelines will help you to understand the fundamental cross cutting factors when designing your chosen application type.
- How to design your exception management strategy
Exceptions can be expensive. Do not use exceptions to implement application logic. Use structured exception handling to build robust code, and use exceptions instead of error codes where possible. While exceptions do carry a performance penalty, they are more
expressive and less error prone than error codes. Write code that avoids unnecessary exceptions. In other words, adopt a defensive coding strategy where checks are made prior to accessing an object or component. Use finally blocks to guarantee that resources
are cleaned up when exceptions occur. For example, close your database connections in a finally block. You do not need a catch block with a finally block. Finally blocks that are not related to exceptions are inexpensive. Do not reveal internal system or application
details, such as stack traces, SQL statement fragments, and so on. Ensure that this type of information is not allowed to propagate to the end user or beyond your current trust boundary. Fail securely in the event of an exception, and make sure your application
denies access and is not left in an insecure state. Do not log sensitive or private data such as passwords, which could be compromised. When you log or report exceptions, if user input is included in exception messages, validate it or sanitize it. For example,
if you return an HTML error message, you should encode the output to avoid script injection.
- How to instrument your application
Instrument your application to measure processing steps for your key scenarios. For example, you may need to measure resource utilization, latency, and throughput to identify where bottlenecks exist in your application. Make your instrumentation granularity
configurable; be able to control event types and switch your instrumentation off completely or switch on extra instrumentation for debugging purposes. Use tracing in both release and debug code to output debugging information, and to check the logic for assertions
in the code. Use custom counters to time key scenarios within your application for performance purposes. Use event tracing to instrument your code with minimum performance penalties. You can log to a WMI sink if you are required to use WMI, and the performance
impact is not excessive. Also consider the manageability of your application, and how you will provide information to administrators and monitoring tools. Construct a health model that describes the state changes for significant entities or sections of your
application, and include instrumentation that allows monitoring tools to detect state changes and provides sufficient and useful knowledge to administrators for maintenance and debugging purposes. Consider the limitations of your deployment scenarios when
designing instrumentation; for example, you may not be able to write to the Windows Event Log in some trust levels.
- How to design for transactions
Transactions can be executed within the database, or they can be executed in the business layer of an application. Where you choose to implement transactions depends on your transactional requirements. If you have business critical operations, consider wrapping
them in transactions. Use connection-based transactions when accessing a single data source. Where you cannot use transactions, implement compensating methods to revert the data store to its previous state. Avoid holding locks for long periods; for example,
when using long-running atomic transactions. Consider using compensating locks for long-running transactions. If the chance of a data conflict from concurrent users is low; for example, when users are generally adding data or editing different rows, consider
using optimistic locking during data access. If the chance of a data conflict from concurrent users is high; for example, when users are likely to be editing the same rows, consider using pessimistic locking during data access. If transactions take a long
time to complete, consider using asynchronous transactions that call back to the client when complete. However, realize that this type of transaction is more complex to implement.
- How to choose between service orientation and object orientation
If you are designing a distributed application, consider a service-oriented architecture. While object-orientation provides a clean view of what a system should look like, and is useful for producing logical models, a purely object-oriented approach often does
not take into account real-world aspects such as physical distribution, trust boundaries, and network communication. If you want to model real-world interactions using verbs and actions, and using objects that contain both data and behavior, consider using
the object-oriented approach. Object orientation focuses on the data that an application manipulates, instead of the processes that it executes. If you want to create applications by assembling services that communicate using a message-based mechanism, consider
using the service-oriented approach. Service orientation provides better reuse of services, interoperability, federation opportunities, and discoverability.
Assume that all input data is malicious. Constrain, reject, and sanitize your input; it is easier to validate data for known valid types, patterns, and ranges than it is to validate data by looking for known bad characters. Validate data for type, length, format,
and range. For string input, use regular expressions. To perform type checks, use the Framework type system. Design client-side validation for user experience, but do not rely on just client-side validation - always validate at the server as well. Encode user
input data before outputting it to a Web page.
- How to address offline and occasionally connected scenarios
Many types of applications must work in offline and occasionally connected scenarios. For these types of applications, do not use automatic synchronization facilities for large datasets. Consider packaging data updates in messages and sending them one at a
time. This allows processing to occur quickly on the single message, and data locks are acquired late and released early. Consider using the MVC and Service Agent patterns, and intelligent use of messaging to avoid deadlocks and data race conditions.
The following guidelines will help you to understand the fundamental factors when designing the presentation layer for your application.
- How to use the MVC pattern
To use the Model View Controller (MVC) pattern effectively, you must understand the division of labor within the MVC triad (the Model, the View, and the Controller). You must also understand how the three parts of the triad communicate with each other and with
other active views and controllers; the sharing of a single mouse, keyboard, and display screen among several applications demands communication and cooperation. The View is the user interface, which displays the data to the user and contains controls for
the user to interact with the data and the application. User interaction in the View raises events to, or calls methods in the Model. The Controller is the logic and code that receives requests and selects the appropriate View. The View handles events raised
by the Controller to update the data that the View displays. The Model exposes the data to be displayed in the View, and contains methods that the controller executes to manipulate this data. It raises events that the Controller handles to display data from
the model. The model is responsible for maintaining state for the user or application.
To implement navigation between Views in the MVC pattern, you typically use the Front Controller pattern. To implement updates between the Model and the Controller you typically use the Observer pattern
- How to use the MVP pattern
In the Model View Presenter (MVP) pattern, the View handles all of the requests or interaction and passes this to the Presenter, which then manipulates the Model and calls back to the View through an interface to initialize data in the View. This pattern supports
a View that uses rich controls, and implements state persistence of controls. The** View represents the user interface, which displays the data to the user and contains controls for the user to interact with the data and the application. User interaction in
the View raises events to, or calls methods in the Presenter. The View handles events raised by the Presenter to update the data that the View displays. The Presenter represents the logic and code that handles events raised by the View, and/or contains methods
called by the View. It manipulates the data displayed by the View by calling methods exposed by the Model. The Model exposes the data to display in the View, and methods that the Presenter executes to manipulate this data. It raises events that the Presenter
handles. The Presenter then displays the data in the View. The Model is responsible for maintaining state for the user or application.**
- How to improve usability of a Web site
Set up your navigation system so that it is easy to use and simple to understand. Create a sitemap to improve navigation, and make it easier to update navigation paths as requirements change. Consider workflows and Wizard-style interfaces for complex processes
that will guide the user, and allow them to step back through the process. Ensure that you provide sufficient help, such as tips and guidance, to allow users to quickly become familiar with and use the application. Consider user empowerment by providing features
that allow users to take control of their environment by modifying and personalizing the UI and the way that the application works. Use asynchronous techniques for long-running processes where possible, and display progress indicators when executing long-running
tasks. Use a common theme for all pages where appropriate. Make sure that your font size is large enough, that your colors contrast sufficiently, and that your headings stand out. Include the recommended features to assist disabled users. Ensure that the application
can be localized and globalized in line with requirements for different languages and cultures. Display meaningful and useful error messages.
The following guidelines will help you to understand the fundamental factors when designing the business layer for your application. The main factor that you should consider is how you will implement business entities.
- How to implement business entities
If you are designing a small Web application or a service, and you want to take advantage of the disconnected behavior they provide, consider using DataSets. If you are working with content-based applications that have few or no business rules, consider using
XML. If you have complex business rules related to the business domain, or if you are designing a rich client where the domain model can be initialized and held in memory, consider using custom Domain Model objects. If your tables or views in the database
represent the business entities used by your application, consider using custom Table Module objects. If the data you are consuming is already in XML format, or if you are working with read-only document-based data, consider using custom XML objects.
The following guidelines will help you to understand the fundamental factors when designing the data layer for your application.
- How to design your data connectivity strategy
If the client and the server are located on the same machine, use shared memory. If you must support communication over the Internet, over wide area networks, or are dealing with slow network connections, use TCP/IP. If the underlying database is Microsoft
SQL Server, use Named Pipes. If you must expose data directly from your database without being required to create an intermediate interface, use HTTP Endpoints. When working with HTTP Endpoints, use Web services as the communication mechanism. If you need
a .NET Framework managed provider for the database, use ADO.NET.
- How to choose between dynamic SQL and stored procedures
In the past, a primary reason for using stored procedures was the improvement in performance compared to dynamic SQL statements. However, with modern database engines, performance is no longer a factor in choosing one over the other. One of the primary reasons
for choosing stored procedures has to do with the fact that a database is one of the top assets for an organization. A stored procedure provides an abstraction layer that can be used to restrict access to underlying objects and mitigate system wide changes
when objects in the database need to change. Stored procedures also provide enhanced security by reducing exposure to SQL Injection attacks, and providing a security model that is much easier to manage. Avoid mixing dynamic SQL within a stored procedure. Avoid
mixing business logic in your stored procedures and in dynamic SQL. When using dynamic SQL, use parameters to help protect against SQL injection attacks, and batch statements to maximize performance. Consider maintainability. For example, decide if it is easier
to update statements in a stored procedure or SQL statements in the compiled code.
- How to improve data access performance
Minimize processing on the server and at the client. Minimize the amount of data passed over the network. Use database connection pooling to share connections across requests. Keep transactions as short as possible to minimize lock durations and to improve
concurrency. However, do not make transactions so short that access to the database becomes too chatty.
- How to pass data across layers and tiers
Prioritize performance, maintenance, and ease of development when you select an approach. Custom classes allow you to implement efficient serialization. Use structures if you can to avoid implementing your own serialization. You can use XML for interoperability
and flexibility. However, XML is verbose and can require considerable parsing effort. Applications that use XML may pass large amounts of data over the network. With the .NET Framework, use a DataReader object to retrieve data as quickly as possible, but do
not pass DataReader objects between layers because they require an open connection. DataSets provide great flexibility; you can use them to cache data across requests; however, keep in mind that DataSet objects are expensive to create and serialize. Typed
DataSet objects permit clients to access fields by name, and avoid the collection lookup overhead.
The following guidelines will help you to understand the fundamental factors when designing the service layer for your application.
When designing a service, consider that messages passed between a service and a consumer can be routed, modified, or lost; which requires a design that will account for the non-deterministic behavior of messaging. When designing your service, keep in mind that
message-based interaction is inherently slower than object-based interaction. Do not mix cross cutting logic such as validation or logging with application logic. Design for idempotency so that the service can manage messages that arrive more than once. Design
for commutativity so that the service can handle messages that arrive in the wrong order. Design for invalid requests by validating them against a schema or known format. Consider using standard elements to compose the complex types used by your service.
- How to expose your application as a service
A Web service consists of provider-side code called skeletons, and consumer-side segments called stubs. Stubs and skeletons are used for marshalling and un-marshalling requests. Start by creating the producer-side components for your service. If your business
functions are already designed in the form of application classes, you can use a bottom-up approach and create a service descriptor (WSDL) from the application classes. If you do not yet have application classes you can build a WSDL contract first and then
generate application classes from it. Once the WSDL contract has been created, using either approach, you can generate producer-side skeletons and client-side stubs from the WSDL definition. Configure and edit the skeleton implementation to link the existing
classes. Add authentication and authorization attributes to the implementation as required. Finally, you can deploy the service.
- How to choose between ASP.NET Web Services and WCF Services for Services
ASP.NET Web Services are a good choice for simple HTTP-based services hosted in IIS. ASP.NET Web Services (ASMX) are generally simpler and easier to create than Windows Communication Foundation (WCF) services. WCF is a good choice for building services with
a SOA-based approach. WCF is also a good choice if you need the performance of TCP communication over HTTP or if you need to host the service without a Web server. WCF provides support for WS*, which includes support for end-to-end security and reliable communication.
WCF allows you to implement duplex communication, and you can also use it with Windows Message Queuing and as a Windows service. In addition, you have more options with regard to protocols, bindings, and formats. Keep in mind that WCF requires .NET 3.0 or
- How to think about Software and Platform Services
Software plus Services (SS) is an approach to application development that combines hosted services with locally executed software. The remote services run over the Internet and are consumed by software on the client, which may be a PC or any other Internet-enabled
S offers the advantages of architectural flexibility, rich user experience, offline capability, cost and time savings, and improved privacy. S+S applications can run when disconnected, but generally do not offer a full feature-set unless connected
to the Internet. Software as a Service (SaaS) is an approach where applications that perform comprehensive business tasks, or accomplish business services, are located on local or remote servers (often owned by hosting organizations) and allow you to consume
them as services with no internal application requirements other than composition and UI.
Platform as a Service (PaaS) is an approach where a core hosting operating system, and optionally plug-in business services, is provided by a remote hosting organization. This allows you to run your own applications or third-party applications obtained from
vendors, on a remote cloud-based system. The benefits of both SaaS and PaaS are reduced management and maintenance requirements for the client, and cost benefits through specialization by the hosting organization and the economies of scale.
- How to choose REST vs. SOAP
The Representational State Transfer (REST) approach suits stateless and/or synchronous interaction with a service by implementing a uniform interface for all resources using the standard GET, POST, PUT and DELETE commands. It is ideal for situation where you
want to use the Web as an open publishing medium, you want to support resource-oriented user interaction, and you want proven scalability. It works best when you support user-driven interaction through forms or you have only a few operations, or when you are
using mashups to implement composition for the UI. The Simple Object Access Protocol (SOAP) approach suits asynchronous interactions that are activity-oriented or service-oriented, and which provide a cross-enterprise communication medium. It works best when
you need a standardized approach to accessing resources, when you need to support orchestrated event flows, or when you have a large number of operations. It also suits the use of business processes that implement composition for the UI.
The following guidelines will help you to understand the fundamentals of applying quality attributes to your application.
- How to identify and evaluate threats
Use threat modeling to systematically identify threats instead of applying security in a haphazard manner. First, identify your security objectives. These objectives help you to focus your threat model and determine how much effort to expend on subsequent steps.
Next, create an application overview. Itemize your application’s important characteristics, assets, and actors to help you identify threats. Next, decompose your application. A detailed understanding of your application will help you uncover more relevant
and detailed threats. Next, identify threats relevant to your application scenario and context. Finally, identify vulnerabilities. Review the layers of your application to determine weaknesses related to your threats. Use vulnerability categories to focus
on areas where mistakes are most often made. Rate the threats based on the risk of an attack or occurrence of a security compromise and the potential damage that could result. This allows you to tackle threats in the appropriate order.
- How to identify and evaluate performance issues
Use performance modeling early in the design process to help you evaluate your design decisions against your objectives before you commit time and resources. Identify your performance objectives, your workload, and your budgets. For example, performance objectives
may include maximum execution time and resource utilization such as CPU, memory, disk I/O, and network I/O. Identify your constraints, such as time and hardware budget. Use load testing and unit tests to measure performance, and identify if hardware or deployment
scenarios are the cause of bottlenecks. Ensure that you test with data types and data volumes that match the actual runtime scenarios.
- How to design for required performance and scalability
Use tried and tested design principles. Focus on the critical areas where the correct approach is essential and where mistakes are often made. Identify requirements, cost, and budget restraints; and whether improvements can come from improving the application
code, changing the deployment approach, or will require additional hardware and infrastructure. Perform design inspections and code inspections to identify poor practice that could lead to bottlenecks. Use the categories described by the performance frame
in this guide to help you organize and prioritize performance issues. Categories include data structures and algorithms, communication, concurrency, resource management, coupling and cohesion, caching, and state management.