J.D. Meier's Blog : Patterns

Cheat Sheet: patterns & practices Pattern Catalog Posted to CodePlex

J.D. Meier — Tue, 21 Oct 2008 17:26:37 GMT

As part of our patterns & practices Application Architecture Guide 2.0 project, we've been hunting and gathering our patterns from across our patterns & practices catalog. Here's an initial draft of our patterns & practices Patterns Catalog at a Glance:

Cheat Sheet: patterns & practices Patterns Catalog (CodePlex)

Pattern Catalog
To collect the patterns, we first identified the key projects that focused on patterns:

Composite Application Guidance for WPF (MSDN)
Data Patterns (MSDN)
Enterprise Solution Patterns Using Microsoft .NET (MSDN)
Integration Patterns (MSDN)
Web Service Security Guidance: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0 (MSDN)

Next, we organized the patterns and summarized in tables. You can browse the tables below to see which patterns are associated with which project.

Composite Application Guidance for WPF

Category	Patterns
Composite User Interface Patterns	Adapter; Command; Composite and Composite View;
Modularity	Event Aggregator; Facade; Separated Interface and Plug In; Service Locator
Testability	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
Distributed 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.
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 Subsystem
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
The following pattern summaries are brief descriptions of each pattern, along with a link to the relevant MSDN pages.

Composite Application Guidance for WPF

Modularity

Service Locator. Create a service locator that contains references to the services and that encapsulates the logic to locate them. In your classes, use the service locator to obtain service instances.

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.
Inversion of Control. Delegate the function of selecting a concrete implementation type for the classes' dependencies to an external component or source.
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).
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.
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.

Data Movement Patterns

Data Replication. Build on the data movement building block as described in Move Copy of Data by adding refinements that are appropriate to 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.
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.
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.
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.
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.
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.
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).

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.
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.
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.
Tiered Distribution. Structure your servers and client computers into a set of physical tiers and distribute your application components appropriately to specific tiers.
Three-Tiered Distribution. Structure your application around three physical tiers: client, application, and database.

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.
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.
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.

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.
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.
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.

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.
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.

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.
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.
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.
Intercepting Filter. Create a chain of composable filters to implement common pre-processing and post-processing tasks during a Web page request.
Page Cache. Use a page cache for dynamic Web pages that are accessed frequently, but change less often.
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.

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.
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.
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.

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.
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.
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.

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).
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).
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.
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.

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.
Brokered Authentication: Kerberos. Use the Kerberos protocol to broker authentication between clients and Web services.
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.
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.
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.

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.
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.

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.

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.

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.

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).

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.

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.

My Related Posts

patterns & practices App Arch Guide 2.0 Project

App Arch Guide 2.0 Overview Slides

Abstract for Application Architecture Guide 2.0

Layers and Components

Key Software Trends

Cheat Sheet: patterns & practices Catalog at a Glance Posted to CodePlex

10 Success Patterns for PMs

J.D. Meier — Wed, 13 Aug 2008 08:59:00 GMT

Here's a brief set of success patterns I've shared with a few colleagues. These are the patterns I see that make a difference in getting results.

10 Success Patterns

Empathic listening.
Rapport before influence
Character trumps emotion trumps logic
Match their style
Ask WIIFY
Distinguish between responsibility and authority
Turn chickens into pigs
Adapt, adjust, or avoid situations
Know the system.
Analyze it over time.

Success Patterns Explained
Here's the essence of each:

Empathic listening. Listen until the other person "feels" they've been heard. Once they feel heard, they're more likely to listen to you. You can do this 1:1 or in a large meeting. Covey uses an "Indian Talking Stick." The person with the stick talks until they feel heard. A former Softie told me his team used an eraser as "the mutex." See Stephen Covey Speaks at Microsoft.
Rapport before influence. This is true whether it’s a presentation, interview … etc.. For example, go to a comedy club and see how the comedian gets the crowd laughing only after they have rapport. See How Might That Be True?
Character trumps emotion trumps logic. If you base all your arguments on logic, but fail to persuade, now you know. See Win the Heart, the Mind Follows.
Match their style. You don't have to go overboard, but a little bridge can go along way. If somebody is visual, could you whiteboard it for them? If somebody's detail oriented, can you provide the details? If somebody needs to hear action, can you turn your ideas into action?
Ask WIIFY. Ask the question What's In It For You? If you're a marketer, this might come natural for you. If you're an engineer, this might feel weird. It's about shifting the focus from the thing to the person. If nobody shows up to your meetings, tailor the invite to be explicit about what's in it for the attendees.
Distinguish between responsibility and authority. Know whether you influence a decision or own it. When you don't have authority, but you need to get results, leverage the model in Influencing Without Authority.
Turn chickens into pigs. A pig's committed while a chicken's involved. Don't let a chicken have a controlling vote, without turning them into a pig. See Turning Chickens into Pigs.
Adapt, adjust, or avoid situations. Learn how to read situations. Some situations you should just avoid. Some situations you should adapt yourself, as long as you play to your strengths. Some situations you should adjust the situation to set yourself up for success.
Know the system. Analyze the problem from a system standpoint. What are the components and subsystems? What are the inputs and outputs? Who are the players? What levers can you pull that make the most impact? If you don't know, who does?
Analyze it over time. Look at the problem or solution over time. Build your temporal skills. The more you play "what ifs" in the future, the easier it gets to anticipate.

Do you have any favorite success patterns to share?

My Related Posts

Patterns vs. Tooling

J.D. Meier — Mon, 12 Nov 2007 10:38:00 GMT

I'm a fan of patterns. I think of patterns simply as problem and solution pairs. I wandered by The Hogg Blog and noticed Jason's post on The Great Debate: Patterns vs Tooling. Since patterns and tooling both have their place, I think there's less of a debate and more of a gap between state of the art and state of the practice.

Why Patterns
I think patterns are an efficient way to share insights. Consolidating 100's of words down into a few is pretty powerful. A pattern language is a great way to map out the terrain of a domain. I think of the pattern language as a constellation of meaningful nuggets. I think the most insighful nuggets are the ones that help you with the toughest forks in the road.

Patterns in Practice
While working on our security and performance guidance, our team was able to rapidly solve and share end-to-end solutions for incredibly complex application scenarios. As we worked through customer scenarios, we would pattern match against our deployment patterns and application infrastructure patterns. To put this in perspective, I remember a customer that had been prototyping a solution for six months, that we solved in ~3 hours because we had a collection of patterns to draw from. We got to a vantage point where we could solve some of the toughest architetural issues for customers in a few minutes. Looking back, I wish we had a more agile way for sharing our learnings with more customers, and I think patterns and pattern languages could have been part of the answer.

Key Usage Scenarios
There's lots of uses for patterns, but here's some examples:

Building vocabulary. A lot of light bulbs went off for me when Ward pointed out that patterns help build a shared vocabulary. It's a way to talk about our craft and to hand knowledge down from one generation to the next.
Sharing solutions. This is what patterns do best.
Encapsulating principles. It's one thing to talk about a bunch of underlying principles. It's another to have a nicely named pattern.

Key Issues with Patterns
Here's some of the issues I've run into with some patterns and repositories over the years:

Problems solved. I don't tend to see enough patterns around the more interesting, engineering problems where patterns are worth the effort. I think quality attributes are great candidates for patterns (security patterns, performance patterns, reliability patterns, flexibility patterns ... etc.)
Locked in print or teasers to more. A lot of the most insightful patterns are locked in print. It makes it tough to share, particularly when we don't all have the same bookshelf.
Bad organization. I've seen only a handful of pattern libraries that impress me. I'm not saying they don't exist, but that I haven't seen a lot I like.
Relevancy. I think one of the biggest issues is just finding relevant patterns for your problem at hand. No matter how well a library of patterns is organized, it still helps to have a shepherd. Web 2.0 can help here.
Bad templates. Sometimes the structure of information is as important as the information.
Bloat. Blah, blah, blah. I'm not a fan of verbosity when I need to get my job done. I've seen some patterns that were more complicated than the solution they were describing.
Vocabulary. While patterns can help build a shared vocabulary, it can be tough in the beginning, like learning yet another vocabulary. Convergence takes time.
Silos and pockets of insight. I don't think patterns are as prevalent as they could or should be. I find a lot of the best nuggets are spread a great deal over time and space.
From concept to code can be a big jump. Sometimes you can't get there from here, or it'a a painful process. I think this is very much a tooling opportunity.
Silly or make-believe patterns. I've come across a lot of patterns that seem to be patterns for the sake of patterns. Ward always told me that the best patterns tell you something you didn't expect or that surprised you.
Lack of anti-patterns. I actually think there's not enough anti-patterns. While there's more than one way to solve a problem, sometimes there's a few places you really shouldn't go, and that's where anti-patterns fit in. Some of the best security insights are documented as anti-patterns.

Key Opportunities for Patterns
I think there's more opportunity than ever for building better pattern libraries and leveraging social software scnearios and tooling opportunities. Here's some examples:

Guidance Explorer. Guidance Exploer lets you easily cross-link patterns or link them to other items. For example, imagine a pattern that links to a code example or a how to or a set of guidelines and checklists. We've also played with the idea of showing patterns as mind maps so you can see the related patterns. Guidance Explorer can also help solve the relevancy issue, by providing more fine-grained organization, as well as make it easy to build a collection of the ones you want. All we have to do is fill up our pattern node with a critical mass of more useful patterns.
Web 2.0. I think Yahoo Design Patterns is a good example.
Tooling support. I'd like to see more drag+droppable patterns and pattern-based modeling going forward.

My Favorite Pattern Guides
Here's a few of the pattern guides I've found to be useful: