Layered Architectures

Layered architectures help to provide a natural level of abstraction between components in a system. We see this pattern all the time in practice. As the book points out, one of the common uses of this pattern is in situations like the OSI network model where requests propagate down through the layers and responses return in the reverse order. In theory, layers are isolated from each other using well defined interfaces. In practice however, this separation can be difficult to achieve. Competing forces such as performance and error handling chip away at these boundaries.

Additionally, layering can introduce unintended consequences. Take for example the TCP/IP model discussed in the text. TCP assumes that a packet loss at a lower layer is due to network congestion. In response to this action, TCP reduces the congestion window and attempts a resend after a predetermined timeout interval. However, what if the standard ethernet datalink layer was replaced with a wireless implementation? Packet loss in a wireless network could simply be due to interference. The proper response to this type of error would be immediate retransmission. However, due to the layered architecture, the upper TCP layer is unaware of the reason as to why the packet was lost and cannot differentiate between the appropriate responses. In an effort to resolve this type of situation, interfaces between layers would need to be refactored to add in the appropriate conduit for data sharing.

One positive attribute of the layered architecture is that it promotes buildability. Interfaces between layers can be well defined and specific layers can be assigned to specific resources and worked on and unit tested in parallel. Once coding is complete, layers can be combined and should hopefully integrate with minimal additional effort.