FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition
Site Archive (Complete)
Architecture Blog: Architecture Styles
Architecture & Design
PATTERN LANGUAGE

Modeling, Managing, Making it Right.

by Jonathan Erickson
IF YOU BUILD IT

... Will they Come?

by Arnon Rotem-Gal-Oz
June 01, 2006

Architecture Styles

Architectural style defines a family of solutions in terms of a pattern of structural organization using a vocabulary made of specific components and connector types and the constraints on their use.

Several styles can be composed to create compound or derived styles (see for example this link which demonstrate how the REST style is derived from other styles).

The definition of architecture style is derived from the definition for software architecture.

Software architecture is the collection of the fundamental decisions about a software product/solution designed to meet the project's quality attribute requirements. The architecture includes the main components, their main attributes and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction (depending on the project's size). If an architecture is to be intentional (rather than accidental)--it should be communicated. Architecture is communicated from multiple viewpoints to cater the needs of the different stakeholders.

(See my post on "What Is Software Architecture".)

The family of related architectures just mentioned is created when you define some of the elements and add constraints on their interactions or as SEI's architecture glossary defines Architecture style:

A specialization of element and relation types, together with a set of constraints on how they can be used.

For example, consider the "Layered architecture" style which is composed of layers (the components) which provides facilities and has a specific roles. The layers have communication paths/dependencies (the connectors).

In a layered style, a layer has some limitations on how it can communicate with other layers (the constraints). Typically a layer is allowed to call only the layer below it and be called only by the layer above it. (That said, there are variants; e.g., a layer can call to any layer below it; vertical layers that can call multiple layers; etc.--as long as the layers communication paths are limited by some rules)

The layered architecture style is very popular to the point of almost being ubiquitous: logical software layers (e.g., presentation component, UI Controllers, business processes, business components, data entities, data access layer), SOA layers (fundamental, Intermediate, Process), physical tiers (e.g., database server, application server, web server and clients) etc.

There are many other architecture styles, including for example pipe and filter, push based, peer-to-peer, blackboard, MVC, PAC, or the more recent Adaptive Object Models, REST (mentioned above) and...SOA (though some will probably disagree ). On my next post I'll explain why I think SOA is an architecture style.

Posted by Arnon Rotem-Gal-Oz at 01:14 AM  Permalink




 
INFO-LINK