Cheat Sheet: patterns & practices Pattern Catalog

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

Composite Application Guidance for WPF

Category Patterns
Modularity Service Locator;
Testability Patterns Inversion of Control; Dependency Injection; Separated Presentation; Supervising Controller; Presentation Model

Data Patterns

Category Patterns
Data Movement Patterns Data Replication; Master-Master Replication; Master-Slave Replication; Master-Master Row-Level Synchronization; Master-Slave Snapshot Replication; Capture Transaction Details; Master-Slave Transactional Incremental Replication; Master-Slave Cascading Replication
Pattlets Maintain Data Copies; Application-Managed Data Copies; Extract-Transform-Load (ETL); Topologies for Data Copies

Enterprise Solution Patterns

Category Patterns
Deployment Patterns Deployment Plan ; Layered Application; Three-Layered Services Application; Tiered Distribution; Three-Tiered Distribution
Distribution Systems Broker; Data Transfer Object; Singleton
Performance and Reliability Server Clustering; Load-Balanced Cluster; Failover Cluster
Services Patterns Service Interface; Service Gateway
Web Presentation Patterns Model-View-Controller; Page Controller; Front Controller; Intercepting Filter; Page Cache; Observer
Pattlets Abstract Factory; Adapter; Application Controller; Application Server; Assembler; Bound Data Control; Bridge; Command(s); Decorator; Façade; Four-Tiered Distribution; Gateway; Layer Supertype; Layers; Mapper; Mediator; MonoState; Observer; Naming Service; Page Data Caching; Page Fragment Caching; Presentation-Abstraction-Controller; Remote Façade; Server Farm; Special Case; Strategy; Table Data Gateway; Table Module; Template Method

Integration Patterns

Category Patterns
Integration Layer Entity Aggregation; Process Integration; Portal Integration
Integration Topologies Message Broker; Message Bus; Publish / Subscribe
System Connections Data Integration; Function Integration; Service-Oriented Integration; Presentation Integration
Additional Integration Patterns Pipes and Filters; Gateway

Web services Security Patterns

Category Patterns
Authentication Brokered Authentication; Brokered Authentication: Kerberos; Brokered Authentication: X509 PKI; Brokered Authentication: STS; Direct Authentication
Authorization Protocol Transition with Constrained Delegation; Trusted Subystem
Exception Management Exception Shielding
Message Encryption Data Confidentiality
Message Replay Detection Message Replay Detection
Message Signing Data Origin Authentication
Message Validation Message Validator
Deployment Perimeter Service Router


Pattern Summaries

Composite Application Guidance for WPF

Modularity 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 http://msdn.microsoft.com/en-us/library/cc707845.aspx
  • Inversion of Control. Delegate the function of selecting a concrete implementation type for the classes' dependencies to an external component or source. See http://msdn.microsoft.com/en-us/library/cc707904.aspx
  • Presentation Model. Separate the responsibilities for the visual display and the user interface state and behavior into different classes named, respectively, the view and the presentation model. The view class manages the controls on the user interface 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 http://msdn.microsoft.com/en-us/library/cc707885.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 Controller or Presentation Model, etc. See http://msdn.microsoft.com/en-us/library/cc707862.aspx
  • 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 user interface 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 http://msdn.microsoft.com/en-us/library/cc707873.aspx

Data Movement Patterns

  • Data Replication.
  • 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 in the more detailed patterns. See http://msdn.microsoft.com/en-us/library/ms978735.aspx
  • Master-Slave 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 http://msdn.microsoft.com/en-us/library/ms978740.aspx
  • Master-Master Row-Level Synchronization. Create a pair of related replication links between the source and target. Additionally, create a synchronization controller to manage the synchronization and connect the links. This solution describes the function of one of these replication links. The other replication link behaves the same way, but in the opposite direction. To synchronize more than two copies of the replication set, create the appropriate replication link pair for each additional copy. See http://msdn.microsoft.com/en-us/library/ms998434.aspx
  • Master-Slave 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 may have occurred to the target replication set are replaced by the new source replication set. See http://msdn.microsoft.com/en-us/library/ms998430.aspx
  • Capture Transaction Details. Create additional database objects, such as triggers and (shadow) tables, and to record changes of all tables belonging to the replication set. See http://msdn.microsoft.com/en-us/library/ms978709.aspx
  • Master-Slave Transactional Incremental Replication. Acquire the information about committed transactions from the source and to replay the transactions in the correct sequence when they are written to the target. See http://msdn.microsoft.com/en-us/library/ms998441.aspx
  • Master-Slave 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. Then they act as sources to move the data to the next replication link and so on until they reach the cascade end targets (CETs). See http://msdn.microsoft.com/en-us/library/ms978712.aspx

Enterprise Solution Patterns

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’s 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 modifying the infrastructure to better suit the component. See 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 http://msdn.microsoft.com/en-us/library/ms978678.aspx
  • Three-Layered Services Application. Base your layered architecture on three layers: presentation, business, and data. This pattern presents an overview of the responsibilities of each layer and the components that compose each layer. See 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 http://msdn.microsoft.com/en-us/library/ms978701.aspx
  • Three-Tiered Distribution. Structure your application around three physical tiers: client, application, and database. See 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 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 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 declaring the class constructor as private so that no other object can create a new instance. See http://msdn.microsoft.com/en-us/library/ms998426.aspx

Performance and Reliability
  • Server Clustering. Design your application infrastructure so that your servers appear to users and applications as virtual unified computing resources. One means by which to achieve this virtualization is by using a server cluster. 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 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 http://msdn.microsoft.com/en-us/library/ms978730.aspx
  • Failover Cluster. Install your application or service on multiple servers that are configured to take over for one another when a failure occurs. The process of one server taking over for a failed server is commonly known as failover. 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 http://msdn.microsoft.com/en-us/library/ms978720.aspx

Services Patterns
  • Service Interface. Design your application as a collection of software services, each with a service interface through which consumers of the application may interact with the service. See 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. Service gateways play a similar role when accessing services as data access components do for access to the application's database. They act as proxies to other services, encapsulating the details of connecting to the source and performing any necessary translation. See http://msdn.microsoft.com/en-us/library/ms998420.aspx

Web Presentation Patterns
  • Model-View-Controller. The Model-View-Controller (MVC) pattern separates the modeling of 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 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 http://msdn.microsoft.com/en-us/library/ms978764.aspx
  • Front Controller. Front Controller 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 transfers 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 http://msdn.microsoft.com/en-us/library/ms978723.aspx
  • Intercepting Filter. Create a chain of composable filters to implement common pre-processing and post-processing tasks during a Web page request. See http://msdn.microsoft.com/en-us/library/ms978727.aspx
  • Page Cache. Use a page cache for dynamic Web pages that are accessed frequently, but change less often. See 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 http://msdn.microsoft.com/en-us/library/ms978753.aspx

Integration Patterns

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 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 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 user interface. The user can then perform the required tasks based on the information displayed in this portal. See http://msdn.microsoft.com/en-us/library/ms978585.aspx

Integration Topologies
  • Message Broker. Extend the integration solution by using Message Broker. 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 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, set of agreed-upon message schemas, set of common command messages, and shared infrastructure for sending bus messages to recipients. See http://msdn.microsoft.com/en-us/library/ms978583.aspx
  • Publish / Subscribe. Extend the communication infrastructure by creating topics or by dynamically inspecting message content. Enable listening applications to subscribe to specific messages. Create a mechanism that sends messages to all interested subscribers. See 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 http://msdn.microsoft.com/en-us/library/ms978572.aspx
  • Function 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 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 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 family of specifications. See http://msdn.microsoft.com/en-us/library/ms978594.aspx
  • Presentation Integration. Access the application's functionality through the user interface by simulating a user's input and by reading data from the screen display. See http://msdn.microsoft.com/en-us/library/ms978588.aspx

Web Service Services Security Patterns

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 http://msdn2.microsoft.com/en-us/library/aa480560.aspx
  • Brokered Authentication: Kerberos. Use the Kerberos protocol to broker authentication between clients and Web services. See 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 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 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 http://msdn.microsoft.com/en-us/library/aa480566.aspx

Authorization
  • Protocol Transition with Constrained Delegation. Use the Kerberos protocol extensions in Windows Server. The extensions require the user ID but not the password. You still need to establish trust between the client application and the Web service; however, the application is not required to store or send passwords. See http://msdn.microsoft.com/en-us/library/aa480585.aspx
  • 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 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 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 cipher-text. Data is encrypted with an algorithm and a cryptographic key. Cipher-text is then converted back to plaintext at its destination. See http://msdn.microsoft.com/en-us/library/aa480570.aspx.

Message Replay Detection
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 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 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 http://msdn2.microsoft.com/en-us/library/aa480606.aspx .

Additional Resources

Last edited Oct 20, 2008 at 7:19 PM by prashantbansode, version 3

Comments

No comments yet.