Patterns and Pattlets
.png "patterns & practices Developer Center")
| Retired Content |
|---|
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Version 1.0.0
Complete List of patterns & practices
Pattlets are actual patterns to which this guide refers, but does not discuss in detail. For more information about why pattlets are used, see Chapter 2, "Organizing Patterns." The following table lists each pattern and pattlet mentioned in this guide.
Table A: Patterns and Pattlets
| Maintain Data Copies (pattlet) | What proven architectural approach should you follow to maintain the content of data that exists in more than one place? | This root pattlet sets the context for the pattern cluster overall. The context is that you have, or are about to create, more than one copy of some data. The general solution is to either synchronously write to the copies from the originating application, or to synchronously post data to a local cache for later movement by an asynchronous service. The timeliness of that movement is given by the requirements of the applications. |
| Application-Managed Data Copies (pattlet) | What proven architectural approach should you follow to design synchronous data management services when you have data held in more than one data stores that are serving applications? | In this case, 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 ensures that copies of the data and/or derived data are updated in the same transaction that changed the original data. |
| Move Copy of Data | What proven architectural approach should you follow to design data movement services when you have data held in data stores that are serving applications, and now you want other applications to use copies of that data? | This is the root pattern for any type of asynchronous writing of copies of data. The pattern presents the fundamental data movement building block, which consists of source, data movement set, data movement link, and target. Transmissions in such a data movement building block are done asynchronously (or eventually) after the update of the source. Thus, the target applications must tolerate certain latency until changes are delivered. |
| Data Replication | What proven architectural approach should you follow to create nearly-identical copies of the data, and possibly also allow the copies to be updated at either the source or target with changes being reflected in each other? | This pattern presents a special type of data movement (replication) with a simple acquisition and manipulation of the data, but possibly a complex write. The complexity of the write generally arises from the need to update both source and target and to eventually exchange the changes to the counterpart. |
| Extract-Transform-Load (ETL) (pattlet) | What proven architectural approach should you follow to create copies of the data when data flows one-way to the target, but getting the data is complex and it needs to be changed a lot before it can be written to the target? | ETL is a type of data movement with possibly a complex acquisition from heterogeneous sources, and/or a complex manipulation with aggregation and cleansing, but always a simple write by overwriting any changes on the target |
| Master-Master Replication | How do you design a replication where the replication set is updateable at either end, the changes need to be transmitted to the other party, and any conflicts need to be detected and resolved? | This is bidirectional data replication between source and target. This includes conflict detection and resolution in order to handle concurrent updates to different copies of the same data in the same transmission interval. |
| Master-Subordinate Replication | How do you design replication when the copy is read-only, or it may be updated but changes to the copied data are not transmitted back, and they may overwritten on a later replication transmission? | This is unidirectional data replication from a source to a target, with overwrite of the target data by the transmission. |
| Master-Master Row-Level Synchronization | How do you design a replication to transmit data from the source to the target and vice versa, when the same replication set is updateable on both sides and you want to resolve conflicts at the row level? | A specific master-master replication where conflict detection and resolution are done at a row level. |
| Master-Subordinate Snapshot Replication | How do you design a master-subordinate replication to copy the entire replication set so that it is consistent at a given point in time? | A specific master-subordinate replication where the complete replication set is acquired from the source, possibly manipulated and written to the target. This design is also used for incremental replications and synchronizations to create the first copy of the data to be maintained. |
| Capture Transaction Details | How do you design a recording of transactional information for all changes to a data store so you can use these as a source for replication? | Design of recording transactional information by means of handcrafted artifacts to be used in an incremental replication using transactional changes. Required if there is no database management system (DBMS) transaction log or if the transaction log cannot be used for any reasons. |
| Master-Subordinate Transactional Incremental Replication | How do you design a replication link to support the transmission of changes using transactional details and replaying them on the target while meeting all integrity constraints? | A specific master-subordinate replication that transmits transactional information from the source and applies it to the target. This ensures that changed data is available to applications only after dependent operations of the same transaction have been replicated as well. |
| Implementing Master-Master Row-Level Synchronization Using SQL Server | How do you implement this design using Microsoft SQL Server? | Guidance to implement synchronization with row-level conflict detection and resolution by means provided with SQL Server merge replication. |
| Implementing Master-Subordinate Snapshot Replication Using SQL Server | How do you implement this design using SQL Server? | Guidance to implement snapshot replication by means provided with SQL Server snapshot replication. |
| Implementing Master-Subordinate Transactional Incremental Replication Using SQL Server | How do you implement this design using SQL Server? | Guidance to implement incremental replication using transactional information by means provided with SQL Server transactional replication. |
| Topologies for Data Copies (pattlet) | What are the proven architectural approaches for creating a topology of data copies for deployments? | The architectural approaches to deploying data copies on several platforms. |
| Master-Subordinate Cascading Replication | How can you optimize the replication of a set of targets in a master-subordinate environment, and minimize the impact on the source? | A deployment design for master-subordinate replications, where the replication from a single source to several targets uses a concatenation of replication links with intermediary databases serving both as target and source. The copies are all related by a need for data from the source replication set. |
| Retired Content |
|---|
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |