Modularity

Service Locator. Create a service locator that contains references to the services and encapsulates the logic to locate them. In your classes, use the service locator to obtain service instances. See "Service Locator" at http://msdn.microsoft.com/en-us/library/dd458903.aspx.

Testability

Dependency Injection. Do not instantiate the dependencies explicitly in your class. Instead, declaratively express dependencies in your class definition. Use a Builder object to obtain valid instances of your object’s dependencies and pass them to your object during the object’s creation and/or initialization. See "Dependency Injection" at http://msdn.microsoft.com/en-us/library/dd458879.aspx.

Inversion of Control. Delegate the function of selecting a concrete implementation type for the classes’ dependencies to an external component or source. See "Inversion of Control" at http://msdn.microsoft.com/en-us/library/dd458907.aspx.

Separated Presentation. Separate the presentation logic from the business logic into different artifacts. The Separated Presentation pattern can be implemented in multiple ways, such as Supervising Presenter or Presentation Model, etc. See "Separated Presentation" at http://msdn.microsoft.com/en-us/library/dd458859.aspx.

Presentation Model. Separate the responsibilities for the visual display and the user interface (UI) state and behavior into different classes named, respectively, the view and the presentation model. The view class manages the controls on the UI, and the presentation model class acts as a façade on the model with UI-specific state and behavior, by encapsulating the access to the model and providing a public interface that is easy to consume from the view (for example, using data binding). See "Presentation Model" at http://msdn.microsoft.com/en-us/library/dd458863.aspx.

Supervising Presenter (or Supervising Controller). Separate the responsibilities for the visual display and the event-handling behavior into different classes named, respectively, the view and the presenter. The view class manages the controls on the UI and forwards user events to a presenter class. The presenter contains the logic to respond to the events, update the model (business logic and data of the application), and, in turn, manipulate the state of the view. See "Supervising Presenter" at http://msdn.microsoft.com/en-us/library/dd490821.aspx.

Data Movement Patterns

Data Replication. Create a replication set and replication link that move data between two locations. A high-level pattern that describes the general process of the more detailed Data Movement Patterns described in this table. See "Data Replication" at http://msdn.microsoft.com/en-us/library/ms978671.aspx.

Master-Master Replication. Copy data from the source to the target and detect and resolve any update conflicts that have occurred since the last replication (due to changes to the same data on the source and target). The solution consists of a two replication links between the source and the target in opposite directions. Both replication links transmit the same replication set in both directions. Such a pair of replication links is referred to as related links. See "Master-Master Replication" at http://msdn.microsoft.com/en-us/library/ms978735.aspx.

Master-Subordinate Replication. Copy data from the source to the target without regard to updates that may have occurred to the replication set at the target since the last replication. See "Master-Subordinate Replication" at http://msdn.microsoft.com/en-us/library/ms978740.aspx.

Master-Master Row-Level Synchronization. Use a pair of related replication links between the source and target and a synchronization controller to manage the synchronization in both directions. To synchronize more than two copies of the replication set, create the appropriate replication link pair for each additional copy. See "Master-Master Row-Level Synchronization" at http://msdn.microsoft.com/en-us/library/ms998434.aspx

Master-Subordinate Snapshot Replication. Make a copy of the source replication set at a specific time (this is known as a snapshot), replicate it to the target, and overwrite the target data. In this way, any changes that might have occurred to the target replication set are replaced by the new source replication set. See "Master-Subordinate Snapshot Replication" at http://msdn.microsoft.com/en-us/library/ms998430.aspx.

Capture Transaction Details. Create additional database objects, such as triggers and (shadow) tables, and record changes of all tables belonging to the replication set. See "Capture Transaction Details" at http://msdn.microsoft.com/en-us/library/ms978709.aspx.

Master-Subordinate Transactional Incremental Replication. Acquire the information about committed transactions from the source and replay the transactions in the correct sequence when they are written to the target. See "Master-Subordinate Transactional Incremental Replication" at http://msdn.microsoft.com/en-us/library/ms998441.aspx.

Master-Subordinate Cascading Replication. Increase the number of replication links between the source and target by adding one or more intermediary targets between the original source and the end target databases. These intermediaries are data stores that take a replication set from the source, and thus act as a target in a first replication link. They then act as sources to move the data to the next replication link and so on until they reach the cascade end targets. See "Master-Subordinate Cascading Replication" at http://msdn.microsoft.com/en-us/library/ms978712.aspx.

Pattlets

Maintain Data Copies. Synchronously write to the data copies from the originating application, or synchronously post data to a local cache for later movement by an asynchronous service. See "Patterns and Pattlets" at http://msdn.microsoft.com/en-us/library/ms998465.aspx.

Application-Managed Data Copies. When a particular application makes a change to its copy of the data, it should then also make changes to the other copies. The application should ensure that copies of the data and/or derived data are updated in the same transaction that changed the original data. See "Patterns and Pattlets" at http://msdn.microsoft.com/en-us/library/ms998465.aspx.

Extract-Transform-Load. A type of data movement that may execute complex queries to acquire data from heterogeneous sources, may apply complex manipulation that includes aggregation and cleansing, but always makes a simple write that replaces any changes on the target. See "Patterns and Pattlets" at http://msdn.microsoft.com/en-us/library/ms998465.aspx.

Topologies for Data Copies. The architectural approaches to deploying data copies on several platforms. See "Patterns and Pattlets" at http://msdn.microsoft.com/en-us/library/ms998465.aspx.

Deployment Patterns

Deployment Plan. Create a deployment plan that describes which tier each of the application’s components will be deployed to. While assigning components to tiers, if it is found that a tier is not a good match for a component, determine the cost and benefits of modifying the component to better work with the infrastructure, or of modifying the infrastructure to better suit the component. See "Deployment Plan" at http://msdn.microsoft.com/en-us/library/ms978676.aspx.

Layered Application. Separate the components of your solution into layers. The components in each layer should be cohesive and at roughly the same level of abstraction. Each layer should be loosely coupled to the layers underneath. See "Layered Application" at http://msdn.microsoft.com/en-us/library/ms978678.aspx.

Three-Layered Services Application. Base your layered architecture on three layers: the presentation, business, and data layers to provide decoupling and increase cohesiveness. See "Three-Layered Services Application" at http://msdn.microsoft.com/en-us/library/ms978689.aspx.

Tiered Distribution. Structure your servers and client computers into a set of physical tiers and distribute your application components appropriately to specific tiers. See "Tiered Distribution" at http://msdn.microsoft.com/en-us/library/ms978701.aspx.

Three-Tiered Distribution. Structure your application around three physical tiers: the client, application, and database tiers. See "Three-Tiered Distribution" at http://msdn.microsoft.com/en-us/library/ms978694.aspx.

Distributed Systems

Broker. Use the Broker pattern to hide the implementation details of remote service invocation by encapsulating them into a layer other than the business component itself. See "Broker" at http://msdn.microsoft.com/en-us/library/ms978706.aspx.

Data Transfer Object. Create a data transfer object (DTO) that holds all data that is required for the remote call. Modify the remote method signature to accept the DTO as the single parameter and to return a single DTO parameter to the client. After the calling application receives the DTO and stores it as a local object, the application can make a series of individual procedure calls to the DTO without incurring the overhead of remote calls. See "Data Transfer Object" at http://msdn.microsoft.com/en-us/library/ms978717.aspx.

Singleton. Singleton provides a global, single instance by making the class create a single instance of itself, allowing other objects to access this instance through a globally accessible class method that returns a reference to the instance. Additionally declare the class constructor as private so that no other object can create a new instance. See "Singleton" at http://msdn.microsoft.com/en-us/library/ms998426.aspx.

Performance and Reliability

Server Clustering. A server cluster is the combination of two or more servers that are interconnected to appear as one, thus creating a virtual resource that enhances availability, scalability, or both. See "Server Clustering" at http://msdn.microsoft.com/en-us/library/ms998414.aspx.

Load-Balanced Cluster. Install your service or application onto multiple servers that are configured to share the workload. This type of configuration is a load-balanced cluster. Load balancing scales the performance of server-based programs, such as a Web server, by distributing client requests across multiple servers. Load-balancing technologies, commonly referred to as load balancers, receive incoming requests and redirect them to a specific host if necessary. The load-balanced hosts concurrently respond to different client requests, even multiple requests from the same client. See "Load-Balanced Cluster" at http://msdn.microsoft.com/en-us/library/ms978730.aspx.

Failover Cluster. A failover cluster is a set of servers that are configured so that if one server becomes unavailable, another server automatically takes over for the failed server and continues processing. Each server in the cluster has at least one other server in the cluster identified as its standby server. See "Failover Cluster" at http://msdn.microsoft.com/en-us/library/ms978720.aspx.

Services Patterns

Service Interface. Create a component that provides an entry point through which consumers of the application can interact with the service, and exposes a coarse-grained interface while decoupling the implementation from the business logic. See "Service Interface" at http://msdn.microsoft.com/en-us/library/ms998421.aspx.

Service Gateway. Encapsulate the code that implements the consumer portion of the contract into its own Service Gateway component that acts as a proxy to other services, encapsulating the details of connecting to the source and performing any necessary translation. See "Service Gateway" at http://msdn.microsoft.com/en-us/library/ms998420.aspx.

Web Presentation Patterns

Model-View-Controller. The Model-View-Controller (MVC) pattern separates the data in the domain, the presentation, and the actions based on user input into three separate classes. The Model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the View), and responds to instructions to change state (usually from the Controller). The View manages the display of information. The Controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate. See "Model-View-Controller" at http://msdn.microsoft.com/en-us/library/ms978748.aspx.

Page Controller. Use the Page Controller pattern to accept input from the page request, invoke the requested actions on the model, and determine the correct view to use for the resulting page. Separate the dispatching logic from any view-related code. Where appropriate, create a common base class for all page controllers to avoid code duplication and increase consistency and testability. See "Page Controller" at http://msdn.microsoft.com/en-us/library/ms978764.aspx.

Front Controller. The Front Controller pattern solves the decentralization problem present in Page Controller by channeling all requests through a single controller. The controller itself is usually implemented in two parts: a handler and a hierarchy of commands. The handler receives the HTTP Post or Get request from the Web server and retrieves relevant parameters from the request. The handler uses the parameters from the request first to choose the correct command and then to transfer control to the command for processing. The commands themselves are also part of the controller. The commands represent the specific actions as described in the Command pattern. See "Front Controller" at http://msdn.microsoft.com/en-us/library/ms978723.aspx.

Intercepting Filter. Use the Intercepting Filter pattern to create a chain of composable filters to implement common preprocessing and post-processing tasks during a Web page request. See "Intercepting Filter" at http://msdn.microsoft.com/en-us/library/ms978727.aspx.

Page Cache. Cache the output generated by the server for pages that are accessed frequently but change less often in order to reduce the processing load on the server. See "Page Cache" at http://msdn.microsoft.com/en-us/library/ms978759.aspx.

Observer. Use the Observer pattern to maintain a list of interested dependents (observers) in a separate object (the subject). Have all individual observers implement a common Observer interface to eliminate direct dependencies between the subject and the dependent objects. See "Observer" at http://msdn.microsoft.com/en-us/library/ms978753.aspx.

Integration Layer

Entity Aggregation. Introduce an Entity Aggregation layer that provides a logical representation of the entities at an enterprise level, with physical connections that support the access and that update to their respective instances in back-end repositories. See "Entity Aggregation" at http://msdn.microsoft.com/en-us/library/ms978573.aspx.

Process Integration. Define a business process model that describes the individual steps that make up the complex business function. Create a separate process manager component that can interpret multiple concurrent instances of this model and that can interact with the existing applications to perform the individual steps of the process. See "Process Integration" at http://msdn.microsoft.com/en-us/library/ms978592.aspx.

Portal Integration. Create a portal application that displays the information retrieved from multiple applications in a unified UI. The user can then perform the required tasks based on the information displayed in this portal. See "Portal Integration" at http://msdn.microsoft.com/en-us/library/ms978585.aspx.

Integration Topologies

Message Broker. Extend the integration solution by using the Message Broker pattern. A message broker is a physical component that handles the communication between applications. Instead of communicating with each other, applications communicate only with the message broker. An application sends a message to the message broker, providing the logical name of the receivers. The message broker looks up applications registered under the logical name and then passes the message to them. See "Message Broker" at http://msdn.microsoft.com/en-us/library/ms978579.aspx.

Message Bus. Connect all applications through a logical component known as a message bus. A message bus specializes in transporting messages between applications. A message bus contains three key elements: a set of agreed upon message schemas, a set of common command messages, and a shared infrastructure for sending bus messages to recipients. See "Message Bus" at http://msdn.microsoft.com/en-us/library/ms978583.aspx.

Publish/Subscribe. Enable classes to publish events that other applications can subscribe to in order to receive specific messages. A Publish\Subscribe mechanism sends events or messages to all interested subscribers. See "Publish/Subscribe" at http://msdn.microsoft.com/en-us/library/ms978603.aspx.

System Connections

Data Integration. Integrate applications at the logical data layer by allowing the data in one application (the source) to be accessed by other applications (the target). See "Data Integration" at http://msdn.microsoft.com/en-us/library/ms978572.aspx.

Functional Integration. Integrate applications at the business logic layer by allowing the business function in one application (the source) to be accessed by other applications (the target). See "Functional Integration" at http://msdn.microsoft.com/en-us/library/ms978578.aspx.

Service-Oriented Integration. To integrate applications at the business logic layer, enable systems to consume and provide Extensible Markup Language (XML)-based Web services. Use Web Services Description Language (WSDL) contracts to describe the interfaces to these systems. Ensure interoperability by making your implementation compliant with the Web Services (WS-*) family of specifications. See "Service-Oriented Integration" at http://msdn.microsoft.com/en-us/library/ms978594.aspx.

Presentation Integration. Access the application’s functionality through the UI by simulating a user’s input and by reading data from the screen display. See "Presentation Integration" at http://msdn.microsoft.com/en-us/library/ms978588.aspx.

Additional Integration Patterns

Pipes and Filters. Implement the transformations by using a sequence of filter components, where each filter component receives an input message, applies a simple transformation, and sends the transformed message to the next component. Conduct the messages through pipes that connect filter outputs and inputs and that buffer the communication between the filters. See "Pipes and Filters" at http://msdn.microsoft.com/en-us/library/ms978599.aspx.

Gateway. Abstracts the access to an external system to a single interface. The pattern eliminates the need for multiple systems to understand how to connect to the external system. Therefore, the Gateway pattern simplifies the development and maintenance processes that are related to accessing external systems. See "Additional Integration Patterns" at http://msdn.microsoft.com/en-us/library/ms978722.aspx.

Authentication

Brokered Authentication. The Web service validates the credentials presented by the client, without the need for a direct relationship between the two parties. An authentication broker that both parties trust independently issues a security token to the client. The client can then present credentials, including the security token, to the Web service. See "Brokered Authentication" at http://msdn2.microsoft.com/en-us/library/aa480560.aspx. The following three patterns describe specific implementations of the Brokered Authentication pattern.

Brokered Authentication: Kerberos. Use the Kerberos protocol to broker authentication between clients and Web services. See "Brokered Authentication: Kerberos" at http://msdn2.microsoft.com/en-us/library/aa480562.aspx.

Brokered Authentication: X509 PKI. Use brokered authentication with X.509 certificates issued by a certificate authority (CA) in a public key infrastructure (PKI) to verify the credentials presented by the requesting application. See "Brokered Authentication: X509 PKI" at http://msdn2.microsoft.com/en-us/library/aa480565.aspx.

Brokered Authentication: STS. Use brokered authentication with a security token issued by a Security Token Service (STS). The STS is trusted by both the client and the Web service to provide interoperable security tokens. See "Brokered Authentication: STS" at http://msdn2.microsoft.com/en-us/library/aa480563.aspx.

Direct Authentication. The Web service acts as an authentication service to validate credentials from the client. The credentials, which include proof of possession that is based on shared secrets, are verified against an identity store. See "Direct Authentication" at http://msdn.microsoft.com/en-us/library/aa480566.aspx.

Authorization

Trusted Subsystem. The Web service acts as a trusted subsystem to access additional resources. It uses its own credentials instead of the user’s credentials to access the resource. See "Trusted Subsystem" at http://msdn2.microsoft.com/en-us/library/aa480587.aspx.

Exception Management

Exception Shielding. Sanitize unsafe exceptions by replacing them with exceptions that are safe by design. Return only those exceptions to the client that have been sanitized, or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service’s inner workings. See "Exception Shielding" at http://msdn2.microsoft.com/en-us/library/aa480591.aspx.

Message Encryption

Data Confidentiality. Use encryption to protect sensitive data that is contained in a message. Unencrypted data, which is known as plaintext, is converted to encrypted data, which is known as ciphertext. Data is encrypted with an algorithm and a cryptographic key. Ciphertext is then converted back to plaintext at its destination. See "Data Confidentiality" at http://msdn.microsoft.com/en-us/library/aa480570.aspx.

Message Replay Detection

Message Replay Detection. Cache an identifier for incoming messages, and use message replay detection to identify and reject messages that match an entry in the replay detection cache. See "Message Replay Detection" at http://msdn2.microsoft.com/en-us/library/aa480598.aspx.

Message Signing

Data Origin Authentication. Use data origin authentication, which enables the recipient to verify that messages have not been tampered with in transit (data integrity) and that they originate from the expected sender (authenticity). See "Data Origin Authentication" at http://msdn2.microsoft.com/en-us/library/aa480571.aspx.

Message Validation

Message Validator. The message validation logic enforces a well-defined policy that specifies which parts of a request message are required for the service to successfully process it. It validates the XML message payloads against an XML schema (XSD) to ensure that they are well-formed and consistent with what the service expects to process. The validation logic also measures the messages against certain criteria by examining the message size, the message content, and the character sets that are used. Any message that does not meet the criteria is rejected. See "Message Validator" at http://msdn2.microsoft.com/en-us/library/aa480600.aspx.

Deployment

Perimeter Service Router. Design a Web service intermediary that acts as a perimeter service router. The perimeter service router provides an external interface on the perimeter network for internal Web services. It accepts messages from external applications and routes them to the appropriate Web service on the private network. See "Perimeter Service Router" at http://msdn2.microsoft.com/en-us/library/aa480606.aspx.