To understand Web 2.0 in pragmatic terms, it helps to review how architects think and work. Architects often see things that are not visible to the naked eye. An architect staring at a skyscraper might be admiring the hidden structural aspects of the building that give it extra rigidity or allow it to move slightly in adverse weather conditions. Architects often admire the whole, while also being able to appreciate the individual parts of a system and their integration into a cohesive unit. Seeing and understanding hidden qualities and aspects of a structure or system often lead to the repurposing of those aspects into new designs. By incorporating such design aspects into new projects, architecture continues to evolve.
There are “architects” in many different fields, working on everything from software systems to commercial buildings, bridges, airports, and much, much more. Architects design, describe, and document systems and their structure, including the internal components, the externally visible properties, and the relationships that exist between them. An architect typically describes and documents all of this in several views to account for static and dynamic behavior during all phases of development and use of a system or structure. These views are generally supplemented with other artifacts depicting additional aspects of the thing being architected. In the case of software, there may be a data model view, a technical infrastructure view, and views from various “actors” who will interface with the system. The term actors in this context refers to any “thing” that interacts with the system, including people or other systems.
Everything has architecture, so why is it so difficult to capture the knowledge of Web 2.0 as architecture?
Architecture encapsulates knowledge about a thing or class of things. Capturing this knowledge successfully requires architects to look beyond a specific implementation and document the concepts behind and relationships between each component in a system/thing in a manner that others can reuse for their purposes. Architects must look beyond what they see or what is visible and capture the axioms, tenets, and idioms in a manner that conveys the most knowledge possible.
Architects use a variety of conventions and formats to preserve knowledge, some of which are arcane and others of which are familiar to most of us. Blueprints are perhaps one of the most common formats, though they capture only part of the knowledge of a structure or system of structures. A blueprint of a building, for example, usually captures only the static structure; it does not describe how actual humans behave in the system. Architects cannot capture the required level of detail in blueprints alone; they use models and patterns of usage to convey additional knowledge that isn’t portrayed in the normative architectural views.
In the software industry, a blueprint is usually synonymous with a component or technology view; it documents aspects that may not be visible to the naked eye. As with a building, the dynamics of how software is used may be just as important as its static structure. When studying Web 2.0, it’s valuable to understand and apply these concepts. Web 2.0 is not just about the static architecture of the Internet; it’s about the patterns of usage between a variety of things, whether human or machine, that use the Internet as a platform.
Patterns, in the context of this book, are abstract designs that may be applied to multiple and diverse manifestations of a common problem. Patterns may be expressed in many formats. However, they generally include three basic elements:
A problem
The context in which the problem occurs
The solution to the problem
For different purposes, different templates for expressing patterns have been built to preserve knowledge in more specific formats. Chapter 6 goes into much greater detail about the process of creating patterns, but here’s a brief explanation to get started.
Austrian-born American architect Christopher Alexander first documented the concept of architectural patterns in his 1970s books A Timeless Way of Building and A Pattern Language: Towns, Buildings, Construction (both from Oxford University Press). In the 1980s, Kent Beck and Ward Cunningham began to experiment with the idea of applying the patterns concepts to the art of software design and development. They presented their results at the annual Association for Computing Machinery OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) conference, and the ideas rapidly spread throughout the IT sector.
Perhaps the best way to explain the concept of architectural patterns is to provide an example. Consider a pattern that captures the concepts of “pants,” including legs, inseam, pockets, and other details. Such a pattern can be used to construct the pants in a variety of materials and/or for many different purposes. (Remember, this isn’t a tightly defined sewing pattern, but a broader description.) For example, if the requirements are pants for warm weather, they can be made with very lightweight cotton, with higher legs for water-wading. For cold weather, the same pattern could be used to make pants that contain an inner lining and are composed of very dense material for thermal efficiency. Both products are easily distinguished from other products that follow the pattern of “skirt” or “shirt.”
Both online and offline, the usefulness of patterns is often tied to their flexibility and reusability in different contexts. As an online example, YouTube implements patterns of Participation-Collaboration, Viral Marketing, and Semantic Web Grounding. It lets its users upload videos and tag them with comments and other terms. It allows URLs to be embedded in any website so that the linked videos can be displayed on that site. YouTube makes video publishers out of anyone who has content to contribute, and it helps people find multiple videos on similar subjects on demand. It doesn’t take a rocket scientist to realize that a simple reapplication of the YouTube patterns for financial services research, cooking recipes, automobile repair information, or books might be a recipe for success.
While a pattern describes functionality shared across any number of implementations, patterns can evolve over time and adjust to meet different needs. Patterns are generally not versioned, and working from a template that allows aspects to be specialized helps others see how it’s been implemented.
Consider the pattern of how musicians, engineers, and audio producers create a multi-track audio work. The pattern involves a producer acting as a centralized controller while music is captured from its analog form and converted into a digital form (with help from the skilled engineer), and then captured for persistence on some media device in the control room, where it is combined with other tracks to create a final audio product. The musician playing the instrument to add to the track listens to other tracks and then plays his part, which is recorded and added by the producer to the final mix, after some post-production tinkering.
Although this pattern is often implemented within the confines of a recording studio where wires capable of transmitting audio signals from one room to another connect various rooms, it may be implemented in a different way. This does not automatically make the pattern mutate into a new version. If the pattern is sufficiently abstract, it should still be valid across varying implementations.
As a general rule, the higher the level of abstraction of a pattern is, the more it can be repurposed. The more specialized a pattern is, the less likely it is that it can be repurposed. For example, you could modify the pattern we just discussed to allow the entire sequence of workflow to happen over the Internet instead of in a recording studio. In fact, startups such as Mix2r, MixMatchMusic, and JamGlue[20] have implemented such a pattern, whereby the producer and the artists use the Internet as a collaborative platform for creating audio productions. Bands can include their fans and friends in the creative process by first posting a set of bed tracks for a song along with information about what they are looking for in the project. Fans can download the bed tracks and then use their own hardware and software to record their instruments alongside the tracks from the band. Once they’re finished, they can upload their tracks as contributions to the final song, and the band’s producer can download those and include them in the mix. This process differs from the typical recording scenario, but it still follows the same general patterns.
Capturing patterns can be an iterative process. Finding patterns involves examining case after case, looking for commonalities amidst the variation. As patterns start to emerge, it becomes possible to capture details of those patterns using a common metamodel or template. In this book, we use an architectural pattern metamodel to express both the static and dynamic aspects of a specific pattern. The metamodel expresses the semantics for each part of the pattern template and sets expectations for the logic of the patterns so that readers can interpret them correctly. This template also captures aspects of the pattern that range from the high-level business story down to specific low-level idioms, some of which may actually contain code samples.
After a core set of patterns has been captured, it becomes possible to describe a larger and more abstract reference model. While the reference model comes after the patterns, it provides a context for their use and makes it easier to tell the story of how they work. We used commonalities within the set of patterns expressed in Chapter 7 as the basis for designing a reference model (discussed in Chapter 4). That model was used as the basis for developing the Web 2.0 reference architecture discussed in Chapter 5.
A model is an abstract representation of a set of concepts or components of a process, system, or structure, generally developed to aid understanding and analysis of a class of things. Models also capture knowledge about the components and concepts and the relationships between them, yet models are different from both architectures and patterns. Most models are abstract, meaning they’re independent of any implementation. Because they are abstract, models cannot be directly implemented: they lack a sufficient level of detail. Figure 1-2 illustrates some of the relationships between models, patterns, and architectures.
As with architectural patterns, the best way to explain the concept of a model is with an example. For that, we’ll return briefly to the architecture industry. In this industry, there is an implied model for all buildings. This model is stated as follows, with all the components in italic font:
Buildings have foundations that mate the rest of the building to the terrain upon which the building may exist. A floor sits on top of the foundation and provides a platform in a three-dimensional existence where forces of gravity react in an aligned manner to pull objects toward the floor. Walls are connected to the floor and act to mark the perimeter of the building. Walls may optionally be used to subdivide the interior of a building into several smaller compartments. Doorways are portals in walls that let things pass from one side of a wall to another. A roof sits on top of the building to mark its uppermost perimeter and to protect the building from the top by providing a barrier.
The model captures and preserves the knowledge of what a building is in terms that are applicable to multiple types of buildings. It is relevant to both a house and a shopping mall, and even to a houseboat. The Web 2.0 model described in this book similarly captures key knowledge that is applicable to many types of Web 2.0 implementations.
Another type of model is a metamodel, which is a specialized model upon which other models can be built. Metamodels are often denoted as “models of models.” The template for capturing Web 2.0 patterns in Chapter 6 can be considered a patterns metamodel.
The first generation of the Internet was largely based on a model commonly referred to as client/server, an abstraction that suggested common styles of interaction. The Web 2.0 model in Chapter 4 is abstract in terms of any specific implementation, yet it captures the knowledge of the major concepts present in multiple Web 2.0 implementations. It supports many full and partial definitions of Web 2.0, such as “a platform of connected devices.” The model also supports the patterns for Web 2.0. It illustrates how the major components and concepts of Web 2.0 interact at a purely abstract level (i.e., not specific to any technology or real-world, concrete implementation).
Figure 1-2 showed how architectural models can be used during a conventional architectural process. Figure 1-3 shows the lineage of mining patterns from examples and then constructing models and architectures based upon those patterns.
Figure 1-3. The methodology used for mining patterns from examples, capturing the knowledge, and then constructing models and architecture based on the commonalities in the patterns
Note that many types of people can do this sort of activity. Entrepreneurs regularly figure out how to solve problems based on certain models without ever really analyzing their processes. Inventors commonly reapply their knowledge to solve new problems and come up with unique ways to do so. You, the reader of this book, also have the ability to use this process map.
In the rest of this book, the term “model” will always mean “reference model.” A reference model is an abstract model that actors use within an environment to understand the key concepts or artifacts within that environment. A reference model is not an architecture. It is a specialized type of model used when variations of the model may be possible. A reference model lets people with differing points of view or definitions use a model as a point of reference to describe their departures from that model. As there are likely to be various definitions of Web 2.0—after all, it would be extremely arrogant of any one group of people to presume that its definition was the universally accepted truth for such a contentious subject—the model in this book is really a reference model, and it can be used by those with differing opinions to explain their differences.
Reference models, like patterns, are not typically versioned. Models should capture knowledge so that they still hold even when the implementation details change. Software architects call this concept durability. Durability is one of the main design goals of the architecture described here and of its component models and patterns.
This point is especially important for entrepreneurs reading this book. A pattern used for tagging and sharing digital photographs could be reapplied, for example, in both an enterprise context (to let employees build their own communities of practice around sets of business data stored on the corporate network and navigated using hyperlinks) and by lone developers building new applications for personal use.
The Web 2.0 model is likely applicable both to the first rendition of the Internet and to what it is evolving into. The model lets you examine the developments of each of its component concepts, independent of the other concepts, to see where true innovations are being made. You could, for example, take the concept of “connectivity and reachability” and see what has evolved in the past 10 years. Examples might include the evolution of the web services family of technologies to include mechanisms for secure, reliable, and transacted messages, as well as the patterns of asynchronous communication between a component of an HTML web page loaded into a client browser and a server or servers. The latter represents an evolution from the old model of having to click the Refresh button and reload the entire page to update the information on a web page. The technology responsible is AJAX, a model for updating parts of a page instead of the page as a whole. Like many other models, AJAX depends on other technologies or architectural paradigms, such as Representational State Transfer (REST).[21]
As you go forward, bear in mind how patterns, models, and architectures relate to each other. The chapters that follow will delve more directly into the field of software architecture and the challenges it presents to those trying to document software systems and infrastructure. In Chapter 2, you’ll start to put this knowledge into practice and apply it to the realm of Web 2.0.
[21] REST refers to a collection of network architecture principles and patterns that outline how resources are defined and addressed, as well as how they may interact with each other, based on the mechanisms defined by HTTP. Dr. Roy Fielding introduced the term in his 2000 doctoral dissertation (see http://en.wikipedia.org/wiki/REST).
Get Web 2.0 Architectures now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
