Charlie Alfred’s Weblog

Architecture Stylin’

There has been some buzz about architecture style recently.  Why should this matter?  Mostly because styles and patterns are our primary defense against “reinventing the wheel.”  They provide a way to pass knowledge about which approaches work in which situations.  But, as an industry, we appear to have serveral very different ideas about what architectural style is.  Or do we?  Are the different definitions just an example of “the blind men describing the elephant?  Are we simply dealing with a problem complex enough that it defies one simple description?

Architectural Styles at 35,000 feet

The table below summarizes 4 descriptions of architectural style, with the significant aspects of each description highlighted in bold.  These descriptions are intended to be representative, not definitive.  But they let help us to contrast some different viewpoints.

Source

Architecture Description Extract

David Garlan & Mary Shaw [1]

(1994)

An architectural style, then, defines a family of such systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined.

Roy Fielding [2] (2000)

Architectural styles are a mechanism for categorizing architectures and for defining their common characteristics. Each style provides an abstraction for the interactions of components, capturing the essence of a pattern of interaction by ignoring the incidental details of the rest of the architecture

Microsoft Application Architecture Guide [3]

(2008)

An architectural style is a set of principles. You can think of it as a coarse-grained pattern that provides an abstract framework for a family of systems. Each style defines a set of rules that specify the kinds of components you can use to assemble a system, the kinds of relationships used in their assembly, constraints on the way they are assembled, and assumptions about the meaning of how you put them together.

Ruth Malan [4]

(2008)

Architectural style distinguishes a set of systems from other systems by identifying the design elements that characterize systems of that style. Alternately put, an architectural style is described by identifying the characteristic features of design that make the style unique.

[1]  http://www.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/intro_softarch.pdf

[2]  http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

[3]  http://www.codeplex.com/AppArchGuide/Wiki/View.aspx?title=Chapter 6 – Architectural Styles

[4]  http://www.ruthmalan.com/Journal/2008/2008JournalJuly.htm#Architectural_Style

Two of these definitions refer to “patterns of structural organization.”  One refers to “essence of patterns of collaboration” while the other refers to “characteristic features.”  Are they talking about the same thing, or something different?

Context: Software vs. Building Architecture

Many who think about software architecture style naturally compare it to building architecture.  At a conceptual level, these two disciplines have a lot of similarity.  Both deal with constructing complex, large scale systems that must master natural forces to be useful, economical, safe, secure, durable, and adaptable.

However, there are important differences between these disciplines:

·       Buildings are constructed of physical materials, subject to constraints of scale, mass, and strength of materials.  The result is highly visible, and has its own asthetics as well as how it fits with the asthetics of its surroundings.

Software, by contrast, is largely conceptual.  Although most software has its own asthetics – for example, the user interface in the iPhone – most of any system is invisible.  While code listings and design diagrams are visible, there is a great deal of critical information that they often fail to reveal.

·       Many building architects, like Christopher Alexander, passionately believe that buildings are alive.  They show how proper use of sunlight and shade change the feel of rooms of a building at different times of day.  They also explain how the flow of people in public areas of large downtown buildings can affect the livability  of an entire area.

If buildings are alive, then software applications are hyper-alive, as if on a permanent high-dose Red Bull intravenous drip.  Software systems are entirely about high-speed, continuous interactions: graphic displays, network messages, algorithms, and disk IO.

A Closer Look at Architectural Styles

Surface-level definitions rarely do justice in illuminating key nuances of a complex subject.  If you dig more deeply into Fielding’s PhD thesis, you will find some interesting observations:

  • Interaction constraints derive from structural constraints.  If we say that a component has a role, we usually mean that it has relationships with one or more other components, and plays certain roles in its interactions with those relationships.  In a Client-Server style, a client role usually initiates communication, while a server passively accepts connections and requests and responds to them.  Sometimes, there are restrictions on which components can be servers, and which can be clients.
  • Fielding believes that styles can be very fine-grained.  I will refer to these as elemental styles, as they are made up of specific constraints on interaction.  Examples of this type of style include Client-Server and Stateless.
  • Fielding also believes that compatible styles can be combined.  By compatible, he means that the interaction constraints defined in one style do not conflict with the other.  I call these composite styles.  Stateless Client-Server is an example of a composite style.
  • Combining styles into composites can create emergent qualities, characteristics or features that result from the synergies between the input styles.  For example, adding the Cache style to Stateless Client-Server improves performance.
  • Since software architecture styles are seen as just an internally consistent set of constraints on component interactions, they can be defined or combined freely to address new problems.  Or, they can be communicated and reused, as needed.

These observations highlight the fact that the order of selecting styles is very important.  If Style A is chosen first, it indentifies a set of components/roles and relationships, and specifies constraints on their responsibilities and interactions.  These constraints are binding on future styles (as well as isolated decisions).  As a result, a style selection is a form of tradeoff decision, as it limits future architecture decisions.

For example, if I choose to use the Pipe and Filter style in one area of a system, I may block myself from using Client-Server in the same area.  Client-Server, by nature, is a bidirectional style, while Pipe and Filter is a uni-directional interaction.

This realization highlights the importance of prioritized Architecture Challenges (see https://charliealfred.wordpress.com/is-architecture-is-not-architecture/ and https://charliealfred.wordpress.com/complexity-driven-2/ for more discussion of this topic).  The first thing to note is the correspondence of architecture challenges and architecture styles.  An elemental or composite style can be used to address a challenge.  The second is that there should be a strong correlation between the most significant architecture challenges and the earliest styles chosen.

An Illustration of Architectural Style

Let’s return to Fielding’s PhD thesis to see a good illustration of this last point.  Fielding shows how the first and second generation World Wide Web are based on a set of combined styles:

·       Early WWW (circa 1992)

o      Client-Server

o      Stateless Server (client holds state and passes to server)

o      Cache (client may hold and reuse copies of results)

·       Modern Web (circa 1998)

o      Layers (each layer only interacts with its neighbors)

o      Virtual Machine (e.g. Java, JavaScript, Flash)

o      Code on Demand (client downloads code to run locally)

o      Uniform Interface  (URI, XML, CSS, HTTP Commands)

A few of these styles are composite styles.  They came into existance by adding constraints to one or more earlier styles to create a new one.  For example:

·       Layered System extends Client-Server, Stateless and Cache by adding transparent layers, like Proxy and Gateway, inbetween the Client and Server.

·       Code on Demand extends Client-Server and Virtual Machine by providing the ability to download executable code.

The most significant composite style in Fielding’s thesis consolidates each of the styles in the original list.  Fielding calls it REST (which is an acronym for REpresentational State Transfer).

As mentioned above, REST is a composite of several styles, including: Client-Server, Stateless, Cache, Layered, Uniform Interface, Virtual Machine, and Code on Demand.  As a result of these component styles, it imposes a number of architecture constraints, including:

1.      The target of each HTTP request is the representation of a resource

2.     A Universal Resource Indicator (URI) is used to identify each resource.

·       The origin server identity is the first part of the URI

·       The remainder of the URI describes the representation uniquely

3.     Object state is transferred in each HTTP Request

·       Passed from client to server as part of the request

·       Returned from the server in response to the request

4.     URI’s must have consistent semantics, and refer to the “same” representation for all time

·       The semantics may refer to an evolving target, like “current version”

·       The semantics may not refer to a variable target, like session-id (resources should not depend on sessions)

5.     In conjunction with the simple set of HTTP commands (Uniform Interface),  URI’s are intended to enable intermediate caching

6.     Attributes specified in the server response identify the lifetime of cachable representations.  This lifetime information is binding on all intermediate layers.

7.     Representations returned by Servers can be static content, or can be executable components that run under the constraints of the browser sandbox and the virtual machine.

This list of constraints describes the core architecture of the Internet that we know and use today.  It gives us massive scalability and redundancy.  It enables Rich Internet client applications using AJAX or Flash, multi-server e-commerce systems.  It is also important to see that a powerful architectural style can be constructed from just 7 component styles, and offers several emergent features while imposing relatively few constraints.

Not only does the REST style yield useful emergent characteristics, its constraints also highlight architectural approaches which violate them.  For example:

  • HTTP Cookies are often used to violate the Stateless constraint.  For example, a Session-Id often refers to a server-specific resource, which holds state for a specific client.
  • SOAP Web Services encapsulate RPC requests in an opaque SOAP envelope.  This compromises the benefits of a uniform interface and caching of representations.

Composite Styles and Classification

Any modern software system is quite likely to have broad scope and incorporate many elemental styles.  In addition, as complexity increases, many of these styles (or combinations) will be invented to address this particular problem.

This complicates the problem of identifying and naming architecture styles.  Two different situations are possible:

  • Over-generalization based on a loosely-defined style.  An example of this would say that the Internet uses a Stateless Client-Server style.  So do hundreds of other systems, most of which have very different architectures than the Web.  It’s nice to know that humans and field mice are both mammals, but that only tells us a small part of the story.
  • Specific naming, based on the combination of specific styles.  With the complexity of modern systems, how  useful is a naming system that combines the names of component styles?  Names like:  Client_Server-Stateless-Cache-Layered-Uniform_Interface-Virtual_Machine-Code_on_Demand are at least as cumbersome as they are descriptive.

A Lesson from Biological Classification

The field of biological classification may provide some inspiration here.  The problem of classifying living organisms is at least as challenging as the problem of classifying architecture styles.

  1. The first potential lesson is the use of hierarchical classification.  The following figure (from http://en.wikipedia.org/wiki/Biological_classification) shows the levels of biological classification, with the more specific categories appearing above the more general ones.

biological_classification1

  1. The next potential lesson is the use of a specific set of criteria to distinguish whether two entities fall in the same or different categories.  Biological classification has a big advantage here.  According to http://www.answers.com/topic/taxonomy:

 “It is important to note just which characteristics of an organism’s morphological aspect (i.e., structure or form) are important to scientists working in the field of taxonomy. In theorizing relationships between species, taxonomists are not interested in what are known as analogous features, those characteristics that are superficially similar but not as a result of any common evolutionary origin. Rather, they are interested in homologous features, those that have a common evolutionary origin, even though they may differ in terms of morphological form.”

In other words, evolution and DNA similarity drives biological classification decisions.  Unfortunately, software architecture doesn’t benefit from a similar scientific basis.

Conclusion

If there is any hope in having a consistent, precise scheme for classifying software architecture styles, I believe that is must start with a common unambiguous scheme for identifying and cataloging elemental styles (or patterns, if you prefer).  Elemental styles like Client-Server, Stateless, Layer, Producer-Consumer, and Model-View-Controller represent the periodic table of architecture styles.  Until we, as an industry, agree on the elements, we will do little but spin our wheels when we try to classify the compounds in a meaningful way.

6 Comments

  1. […] Architecture Stylin’ […]

    Pingback by My two-cents about architecture style « Charlie Alfred’s Weblog — December 21, 2008 @ 6:16 pm

  2. Brilliant post! I’ve been thinking about design or architectural styles quite a while, without going much further than styles as bags of patterns and idioms “that go well with each other”.

    Emergence
    You push that much further, as not only they go well with each other, but they also have emergent properties, and obviously, REST is a great example of that emergence.

    Social identification with peers
    I see styles in software just like schools of painting (Impressionists, Cubists etc.), where each painter is able to claim which school he belongs to, and quote some leaders names. I could say “I feel close to the ex Smalltalkers that became OO, Patterns and Agile leaders, like Beck, Fowler etc.”.

    Constraints
    You say “Client-Server, by nature, is a bidirectional style, while Pipe and Filter is a uni-directional interaction”; could styles be also defined, just like in painting, by a constraint we decide to follow in order get some benefits?

    Paradigms may also impose constraints such as “no side-effect” in Functional programming are also important in this topic. Are they styles or something even bigger? Is every pattern language a style as well?

    Completeness
    By contrast with the work of Alexander, our patterns and pattern languages in software are not complete enough to account for a whole project design. I have the feeling that Eric Evans Domain-Driven Design comes close to that end, especially with the strategic design part.

    Ideally, I’d love to be able to trace back each class and method to the design decision it comes from (e.g. implementation idiom), and again to the bigger design decision (e.g. a pattern), and again (coarse grain pattern), and again until one overall style at the root. Each design decision / pattern in this tree must be logically linked to its higher and lower level partners, typically with a relation of consumer (expresses an intent) / provider (satisfies the intent). Just like everything else, styles of course are chosen because they address some feature or concern required for the software to provide value. Hence if I were to classify I’d require the classification to consider intents with great attention.

    Comment by cyrille — March 26, 2011 @ 12:40 pm

  3. Cyrille,

    Thanks for your very thought-provoking comment. I agree with the observations you make under the Emergence, Social Identification, and Constraints comments.

    But I believe that the critical question is the “Completeness” one. One of the questions that has always challenged my thinking about patterns is: “What comes first, the pattern or the context?”

    As an industry, do we catalogue and collect patterns, then apply them to problems, like an artist applies paint and texture to a canvas? Or, do we learn to sense opposing forces, variations, and uncertainties in the problem space, like an artist is driven by the subtleties in a real or imaginary vision? Or do we recognize how to match the two?

    Personally, I think its the 3rd option, but if I had to choose between the first two, I lean toward the second. I think it is necessary to study patterns, like a guitarist or pianist studies chords. However, I often find that music is a mechanical assembly of chord progressions. Brilliant music starts with the end, and seems to discover the chords and rhythm that express it.

    Charlie

    Comment by charliealfred — March 26, 2011 @ 1:04 pm

  4. I’m with you on the “completeness” being an important question. And I also do not believe that we catalogue and then apply patterns as cookie-cutting solutions found in the catalogue. As you said, we study them more to practice and feel how they resolve the forces, more like kata in martial arts.

    In real life, we spend a lot of energy to justify and “rationalize” a posteriori what we’ve done without really thinking.

    However, with higher maturity (as in the conscious competence theory aka “Four Stages of Learning”) we becomes increasingly able to declare what we’ve just done, e.g. using patterns, which like any specialized vocabulary, make communication more formal and faster (by the way I appreciated very much your other pages on that point…).
    This is why I’d like to “trace” design decisions, as in traceability, even a posteriori, in order to express intents, make design more explicit, justify the done design, and why not enable some tooling. This calls for more completeness, and probably we only need to put some more names on things we already do to achieve that.
    Cyrille

    Comment by cyrille — March 26, 2011 @ 3:51 pm

  5. Cyrille,

    I agree with you very much about tracing design decisions to intent, as well as to the challenges that motivate both approaches and tradeoffs. This is one of the most important things that a development team can do to increase long term stability of a software system.

    Over the past few years, I’ve published two articles that describe an approach that begins with context(s), identifies challenges, and traces them through architectural decisions. In case you might be interrested, the URL’s are: http://msdn.microsoft.com/en-us/library/aa480060.aspx and http://msdn.microsoft.com/en-us/ff476942.aspx.

    Charlie

    Comment by charliealfred — March 26, 2011 @ 4:08 pm

  6. […] for all practicing architects.  If you are skeptical, take a few minutes to read my article at https://charliealfred.wordpress.com/architecture-stylin/ and leave a comment to let me know if you agree or […]

    Pingback by My two-cents about architecture style | The Agile Radar — December 8, 2011 @ 1:11 pm


RSS feed for comments on this post. TrackBack URI

Blog at WordPress.com.

%d bloggers like this: