Sound advice - patterns

Tales from the homeworld

My current feeds

Sun, 2008-Jul-06

Published: Wed Jul 2 20:38:52 EST 2008

Updated: Sat Jul 5 21:53:36 EST 2008

Layering

Intent

Intercede between client and server to achieve performance or functionality benefits.

Motivation

Server S wants to serve get requests for five clients, but does not have resources to serve GET requests for all directly. A layer of indirection is added between the server and its clients that shields the server from requests for resources that already have cached documents. The cache returns responses on behalf of the server, reducing the need to generate responses from scratch.

Applicability

  1. Caching Proxy: A proxy that is trusted by a set of clients to act on their behalf. A chain of trust may be established from proxy to proxy in a well-managed network. Caching proxies are generally employed in networks where there the information being transferred is non-secret. Proxies are generally bypassed for secret communications. Protocol handling libraries for REST clients often act both as a Caching Proxy for the client of its API and a gateway from an API-based REST model to that of a specific protocol.
  2. Gateway: A proxy trusted by a set of clients to speak a protocol or participate in patterns not widely understood throughout the architecture. Gateways are generally temporary measures as different architectures come into contact with each other, before they consolidate their organisational structures to effectively deal with their common requirements.
  3. Firewall: A proxy that inspects requests passed through it to make sure they fit defined policy boundaries. The firewall might limit PUT access to certain URLs, remove portion of requests that it considers dangerous, or monitor patterns of requests to actively detect attempts at intrusion.
  4. Content Distribution Network: A proxy trusted by the server to answer requests on behalf of clients. The CDN is part of a chain of trust that extends outward from the server, and can be considered to be operated by the same agency as the server's. CDNs are used to provide local service to clients that may be distant from the main data centre, and may have various forms of private access to Server-side data not generally afforded to clients.

Structure

Layering pattern structure

Participants

Intermediary
  • Accepts requests from Client and generates requests to Server. Requests are submitted in whole, so can be passed on without significant modification as-is. The Intermediary is capable of performing alternate processing on behalf of the server such as returning a cache entry or manipulating requests and responses.

Collaboration

  • Client issues requests to Intermediary instead of Server. Intermediaries may be discovered by explicit configuration of Client, implicitly as part of the network configuration, or as an explicit redirection response from Server (see HTTP's 305 Use Proxy response).
  • Intermediary processes the request. It answers it itself or optionally modifies the request and passes it on to Server.
  • Server accepts requests from Intermediary and processes them as if they had come from Client.
  • The server's response is processed by Intermediary, optionally modified, and returned to Client.

An arbitrary number of layers can be added, each treating the next as Server and the previous as Client.

Consequences

The Layering pattern increases latency for requests that are forwarded unmodified, but can provide performance and functionality improvements when caching or other modifications are applied successfully.

Introducing layers increases the complexity of security, architecture evolution, and simple component testing models. Security and trust become an issue as intermediaries move further from the ownership of either Server or Client. Intermediaries literally are the feared man in the middle of security parlance. An intermediary that chooses to function against the interests of either Client or Server will lead to compromised communication.

Evolution of the architecture can be stymied by intermediaries. Upgrade of client and server to participate in a new operation or pattern is often not sufficient. The presence of old intermediaries under control of neither the Client's agency or the Server's agency mean that work-arounds and fallbacks may be required when they otherwise would not be required.

Testing of components can also suffer. Testing against common Server implementations is not sufficient if an intermediary introduces an unknown factor. Intermediaries may re-order pipelined request messages, splitting a single TCP connection at the Client end into multiple connections by the time they reach the Server. This is a potential source of out of order processing and other mischief that testing only a Client/Server combination may fail to reveal.

Implementation

Sample Code

Known Uses

Layering is widely used on the Web. It is used to implement caching in most HTTP client libraries. Caches are still sometimes used in ISPs to reduce traffic costs on behalf of clients that issue GET requests to similar sets of URLs. Layering is very commonly used as part of the network on the server-side, with load balancing and vertical scaling techniques strongly leveraging this pattern. Content Distribution Networks are becoming more commonly leveraged to serve a global audience with low latency.

Related Patterns

Sun, 2008-Jul-06

Published: Wed Jul 2 20:38:52 EST 2008

Updated: Sun Jul 6 12:25:07 EST 2008

Registry

Intent

Support serendipitous reuse across an architecture

Motivation

Producer P and consumer C want to transfer a document. P has a particular abstract data schema in mind, and C has a compatible schema. Registry ensures that P encodes and transmits the information in a form that C understands.

The methods for applying patterns of information transfer and forms in which information are encoded may be defined either by local convention or by a wider convention. Local protocols may be "jargonised" versions of more widely-applicable protocols. In time, jargon may move from a satellite architecture such as that of a particular enterprise and become standardised in a wider setting such as the Web.

Applicability

Registry is applicable for REST architectures large and small. However, architectures with only a small number of components may not need a formal registry.

Structure

Registry Structure

Participants

Document Type
  • Provides a defined way to encode a given information schema
  • May have one or more parent types, whose parser is also appropriate to read this derived document type
  • Is defined in a Document Type Specification, including accommodation of document type evolution through must-ignore semantics on information that is not understood by processors.
  • May be a target encoding for a number of a number of different information schemas, including internal information schemas for various kinds of applications. For example, HTML can be used to encode information schemas as diverse as journal entry publication and warnings about severe weather events.
  • May act as a bridge between different Information Schema. For example, ODF is able to bridge between OpenOffice and Gnome Office internal document schemas.
  • Is defined to be independent of how it is transported, and orthogonal to Operations that are defined in the architecture.
  • Is developed using the least power principle: The least powerful language that is capable of expressing a set of information is used.
  • Minimises coupling by limiting reliance on local or domain-specific conventions.
Operation
  • Provides a way to transport information around the architecture
  • Corresponds to one or more Interaction Patterns that are understood by applicable information end-points
  • Is defined to be independent of the information it transports, and the specific endpoints it transfers information between. Operations are orthogonal to the set of URLs in the architecture.
Management Body and Process
  • Manages the evolution of Document Types and Operations
  • Oversees the adoption and uptake of new or updated Document Types and Operations in the architecture
  • May depend heavily on external bodies, especially those that manage the Web
  • Typically do not have the authority to upgrade any given component of the architecture. Instead, components are upgraded over time as their respective owners see fit in line with the Registry specifications.
  • Typically do not have any control over the set of URLs in the architecture

Collaboration

  • The Management Body and Processes manages the independent evolution of Document Types and Operations in the architecture. The set of URLs is not controlled by this body.

Consequences

The orthogonal nature of document types, operations, and URLs throughout the architecture allow for freedom of evolution. This separation and evolution is supported through the major patterns of the architecture as old and new components interact, including GET and PUT.

The balance of control and freedom is capable of delivering application-level forwards and backwards compatibility that lasts for a relative eternity in our industry. For example, HTML and HTTP have been able to continuously evolve over a time-frame spanning decades.

More domain-specific document types will likely have shorter lifespans as they develop from local conventions to a point of widespread global agreement. However, as critical mass is created a semantic web where machines can communicate generally based on widely-understood conventions is likely to emerge without specific coordination or intervention.

Implementation

Sample Code

Known Uses

The IETF defines a registry and change management process that includes a list of protocol interactions for document transfer (HTTP/1.1) and legal document types (the IANA).

Related Patterns