Layered Versus Client-Server

 

Roger Hill

May 2007

Summary: Beware: Architectural advice from local experts might not be correct. Each architecture style has a distinct purpose for communicating a specific understanding. An architect has the responsibility to understand the styles and employ them by representing the information in the appropriate drawings. (5 printed pages)

Contents

Architecture Styles
The Module Viewtype
The Component-and-Connector Viewtype
The Allocation Viewtype
Layered Versus Client-Server
Conclusion
Critical-Thinking Questions
Sources
Further Study
Glossary

Architecture Styles

Nicole Holliday, an experienced programmer/analyst who has recently joined the architecture team, met with me the other day; she wanted to know more about architecture styles. She was determined to learn quickly about architecture principles and practices that she would need in her new position, and was taking evening classes on software architecture from State University. She explained that, in her class, her student team was applying boxology [Shaw & Clements 1997] to discover the architecture styles of existing applications. She wanted to know more about architecture styles and why a project-development team would use one over another, or perhaps together. I congratulated her on being committed to continuing her education and, especially, in the area of software architecture. I was impressed when she shared with me that she had graduated Phi Beta Kappa from Stanford, and still enjoys the "Love of Wisdom" that the honor society espouses. I then briefly introduced her to the documentation concept of viewtypes [Clements et al. 2003] and explained how architecture styles could be used together to document different perspectives of a software solution.

The Module Viewtype

Architecture styles that are compiled into a "module" viewtype are used to define the decomposition and organization of functionality, for implementation into a coherent set of software code. These styles are used to describe the structure of the software units, identify the individual units, document the functional responsibilities of each unit, and define the interface characteristics between the units. A set of module viewtypes that show the decomposition of functionality—from the high-level abstraction to the excruciating level of implementable details—are used to communicate requirements traceability and to provide a foundation for impact analysis.

Documenting the sequences of invoking modules can provide insight into overlapping functionality and aid in gap analysis. The relationships between the units are the interfaces. One might want to expose some of the interfacing data from prior functional units, or only expose data from the current unit by encapsulating (hiding) the information from the previous processing. Elements in module viewtypes are commonly mapped to elements in the architecture styles that are found in "component-and-connector" viewtypes. Be careful not to overload module elements with elements from other viewtypes. When documenting a viewtype, keep it clean. When combining architectural styles, maintain separation of information in the appropriate views.

The decomposition architecture style employs an "is-part-of" relationship between the module elements. It is used to show the decomposition of a unit into subunits, or to show how functional responsibilities are partitioned across modules. The uses style indicates dependency with the "uses" relationship between module elements. It documents what modules must exist for the using module to perform correctly. The generalization style is used to depict "is-a" relationships between module elements. The parent (or generalization) element documents the responsibilities that are common across all child (or specialization) elements. The layered style represents a stack of virtual machines with the "allowed-to-use" relationship. Layered architecture provides for a high level of modifiability and portability.

The Component-and-Connector Viewtype

The component-and-connector (C&C) viewtype documents the run-time process, data stores, clients, servers, and interactions. It documents the control flows and data flows of the components of the executable application. C&C diagrams are typically the box-and-line representations of applications that IT managers like to display on conference-room walls.

The component elements are representations of clients, servers, filters/transformations, objects, and databases. Interfaces between components are referred to as "ports," to emphasize their run-time nature. All ports should be explicitly documented, as should the connectors are procedure calls, database calls, messaging, and asynchronous data streams. A significant defect in many C&C architecture diagrams is the absence of naming the connectors. All elements in the architecture must be explicitly identified and defined. Anything less than this is not architectural drawing; they are only cartoons.

Because data flow and control flow topologies are not always synchronous, they should both be represented independently on the diagram. For complex systems, different diagrams should be used to represent the two flows. A mapping between elements of the C&C models and the elements of the module viewtype adds greater understanding to component and connector information. The architecture styles in the C&C viewtype are:

• Pipe-and-filter.
• Shared-data.
• Publish-subscribe (or pub/sub).
• Client-server.
• Peer-to-peer.
• Communication processes.

The Allocation Viewtype

The allocation viewtype documents how and where the software architecture maps to the environment. The programs, databases, and interfaces of the C&C viewtype are mapped to the hardware with the deployment style. The modules are mapped to the systems using the implementation style. The modules are mapped to people (roles, groups, teams, organizations) who are chartered with the development, maintenance, and operation of the modules by using the work-assignment style.

Layered Versus Client-Server

I assured Nicole that, by understanding the architecture styles and the boxology, she would be a better architect than many who have that title, but who have failed to learn the fundamentals of their job. Just then, another senior member of the architecture team headed towards us to join the conversation. He is a lead architect who knows all of the buzzwords, but has avoided learning anything new since COBOL 74. I mentioned to Nicole that I would use this opportunity to demonstrate the value of having a solid foundation in knowing and understanding the software-architecture styles.

The lead architect sat down with us and I greeted him by saying, "Hi, Ken! Nicole and I were just talking about architecture styles. Would you like to share your thoughts on the layered style and the client-server style?" For the next few minutes, he misrepresented them as being essentially the same—saying that the layers are the user-interface client tier, the logic tiers, and data-server tier of client-server architecture.

He had fallen into the common, predictable trap. This is not only a verbal trap, but is a reality on numerous architecture drawings. Many architects try to show their designs as layered or as client-server, even when they are not. All too often, software architecture is forced into representations that are familiar to the designer, instead of appropriate for the design, and the most commonly abused architectural styles are these two styles.

The client-server–architecture style is categorized in the C&C viewtype, which is used to express run-time behavior. The client-server style shows a component's interactions with other components by requesting services of the other components. Communication between the components is typically a bidirectional pairing of "uses" relationships. One misconception is that client-server elements call (or invoke) other elements. "Uses" relationships are not necessarily invoked with a call, and calls do not necessarily imply that anything is used. An element in one tier sends a request to an element in another tier and expects information back. The tiers in this style are actually a result of hybridizing the C&C viewtype and the allocation viewtype.

The layered-architecture style is categorized in the module viewtype, and the relationships between the modules are typified with the relationships of "is part of" or "inherits from." With each layer being a collection of related code, they act as a virtual machine that is independent of the other layers. The communication between the layers is hierarchical in nature, with the higher-order layers passing control to lower-ordered layers. An element in one layer sends information to an element in the next layer and is done with it; no information is expected back. Because the layered style might indicate an "allowed-to-use" relationship, it can be easily confused with the C&C viewtypes. To avoid this trap, the architect should differentiate between the "allowed-to-use" and the "uses" relationships by focusing on the direction of the communication and following Clements's admonition that "upward uses invalidate layering" (Clements, p. 94).

In the layered-architecture style, each layer represents a well-defined, distinct set of functional responsibilities, with obvious interface boundaries between the layers. The layers are a highly cohesive set of functionality that is implemented as an ordered set—referred to as a "stack." Control is passed from one layer to the next sequential layer, down the stack. The layered style does allow for out-of-sequence anomalies, such as occasionally skipping a layer or jumping back up the stack. Although layers can be a module, they are not always so. Modules can be decomposed into other modules, whereas the virtual machines cannot. Layers are often confused with "tiers" in client-server architectures.

Conclusion

Each architecture style has a distinct purpose for communicating a specific understanding. An architect has the responsibility to understand the styles and employ them by representing the information in the appropriate drawings. Ken did not understand this foundational knowledge and had unknowingly embarrassed himself by assuming information, instead of learning it. Nicole had enough recent experience working with the boxology to know that Ken's perspectives were faulty. Noticing Nicole's expression, Ken quickly excused himself by claiming that he needed to get back to his desk and work on a late deliverable. I then explained the preceding information to Nicole—emphasizing the importance of the "direction" of the relationships as a key determinant between the layered architecture style and the C&C style.

Critical-Thinking Questions

• Why is it important to understand different architecture styles?
• Would a pipe-and-filter style be better for an online-transaction processing (OLTP) or a warehouse application? Why?
• What is meant by synchronous and asynchronous topologies?

Sources

• [Clements et al. 2003] Clements, Paul, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, and Judith Stafford. Documenting Software Architectures: Views and Beyond. Boston, MA: Addison-Wesley, 2003. [ISBN 0201703726]
• [Shaw & Clements 1997] Shaw, Mary, and Paul Clements. "A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems" (a white paper for the 21st Int'l Computer Software and Applications Conference, August 1997, pp. 6–13; online posting accessed on December 2, 2006).

Further Study

• Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice. Second Edition. Boston, MA: Addison-Wesley, 2003. [ISBN 0321154959]
• Shaw, Mary, and David Garlan. Software Architecture: Perspectives on an Emerging Discipline. Upper Saddle River, NJ: Prentice Hall, 1996. [ISBN 0131829572]

Glossary

Boxology—A hierarchical classification of software-architecture styles. It was first defined by Mary Shaw and Paul Clements in 1997 at Carnegie-Mellon University. It bares the name "boxology," from the graphical representation of nodal boxes connected by lines.

 

About the author

Having engaged in software development since the mid-1970s, Roger Hill has embraced the evolution of software-development life-cycle methodologies and practices over three decades of study and development. He has developed systems for finance, retail, inventory management, and design engineering. Roger has written papers on reverse engineering, defining components, and strategic alignment of software projects. He continuously participates in learning opportunities, and holds a Masters of Science degree from Carnegie-Mellon University.

This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.