34.3. Other Layer Pattern Issues
In addition to the structural and collaboration issues discussed above for the Layers pattern, other issues include the following.
Logical versus Process and Deployment Views of the Architecture
The architectural layers are a logical view of the architecture, not a deployment view of elements to processes and processing nodes. Depending on the platform, all layers could be deployed within the same process on the same node, such as an application within a handheld PDA, or spread across many computers and processes for a large-scale Web application.The UP Deployment Model that maps this logical architecture to processes and nodes is strongly influenced by the choice of software and hardware platform and associated application frameworks. For example, J2EE versus .NET influence the deployment architecture.There are many ways to slice and dice these logical layers for deployment, and in general the subject of deployment architecture will only be lightly introduced, as it is non-trivial, largely outside the scope of the book, and dependent on detailed discussion of the chosen software platform, such as J2EE.
Is the Application Layer Optional?
If present, the Application layer contains objects responsible for knowing the session state of clients, mediating between the UI and Domain layers, and controlling the flow of work.The flow may be organized by controlling the order of windows or web pages, for example.In terms of the GRASP patterns, GRASP Controller objects such as a use case facade controller are part of this layer. In distributed systems, components such as EJB session beans (and stateful session objects in general) are part of this layer.In some applications, this layer is not required. It is useful (this is not an exhaustive list) when one or more of the following is true:
- Multiple user interfaces (for example, web pages and a Swing GUI) will be used for the system. The Application layer objects can act as Adapters that collect and consolidate the data as needed for different UIs, and as Facades that wrap and hide access to the Domain layer.
- It is a distributed system and the Domain layer is on a different node than the UI layer, and shared by multiple clients. It is usually necessary to keep track of session state, and Application layer objects are a useful choice for this responsibility.
- The Domain Layer cannot or should not maintain session state.
- There is a defined workflow in terms of the controlled order of windows or Web pages that must be presented.
Fuzzy Set Membership in Different Layers
Some elements are strongly a member of one layer; a Math class is part of the Foundation layer. However, especially between the Technical Services and Foundation layers, and Domain and Business Infrastructure, some elements are harder to classify, because the differentiation between these layers is, roughly, "high" versus "low," or "specific" versus "general." which are fuzzy set terms. This is normal, and it is seldom necessary to decide upon a definitive categorizationthe development team may consider an element roughly part of the Technical Services and/or Foundations layer considered as a group, broadly called the Infrastructure layer.[1]
[1] Note that there are not well-established naming conventions for layers, and name overloading and contradiction in the architecture literature is common.
For example:
- Suppose this is a Java technologies project, and the open source logging framework Log4J (part of the Jakarta project) has been chosen. Is logging part of the Technical Service or Foundation layer? Log4J is a low-level, small, general framework. It is moderately a member of both the Technical Services and the Foundations fuzzy sets.
- Suppose this is a Web application, and the Jakarta Struts framework for web applications has been chosen. Struts is a relatively high-level, large, specific technical framework. It is arguably strongly a member of the Technical Services set, and weakly a member of the Foundation set.
But, one person's High-level Technical Service is another's Foundation…Finally, it is not the case that the libraries provided by a software platform only represent low-level Foundation services. For example, in both .NET and J2SE+J2EE, services include relatively high-level functions such as naming and directory services.
Contraindications and Liabilities for Layers
- In some contexts, adding layers introduces performance problems. For example, in a high-performance graphics-intensive game, adding layers of abstraction and indirection on top of direct access to graphics card components may introduce performance problems.
- The Layers pattern is one of several core architectural patterns; it is not applicable to every problem. For example, an alternate is Pipes and Filters [BMRSS96]. This is useful when the main theme of the application involves processing something through a series transformations, such as image transformations, and the ordering of the transformations is changeable. Yet even in the case when the highest level architectural pattern is Pipes and Filters, individual pipes or filters can be design, with Layers.
Known Uses
A vast number of modern object-oriented systems (from desktop applications to distributed J2EE Web systems) are developed with Layers; it might be harder to find one that is not, than is. Going farther back in history:
Virtual Machines and Operating Systems
Starting in the 1960s, operating system architects advocated the design of operating systems in terms of clearly defined layers, where the "lower" layers encapsulated access to the physical resources and provided process and I/O services, and higher layers called on these services. These included Multics [CV65] and the THE system [Dijkstra68].Earlier stillin the 1950sresearchers suggested the idea of a virtual machine (VM) with a bytecode universal machine language (for example, UNCOL [Conway1958]), so that applications could be written at higher layers in the architecture (and executed without recompilation across different platforms), on top of the virtual machine layer, which in turn would sit on top of the operating system and machine resources. A VM layered architecture was applied by Alan Kay in his landmark Flex object-oriented personal computer system [Kay68] and later (1972) by Kay and Dan Ingalls in the influential Smalltalk virtual machine [GK76]the progenitor of more recent VMs such as the Java Virtual Machine.
Information Systems: The Classic Three-Tier Architecture
An early influential description of a layered architecture for information systems that included a user interface and persistent storage of data was known as a three-tier architecture ( TK78]. The phrase did not achieve popularity until the mid 1990s, in part due to its promotion in [Gartner95] as a solution to problems associated with the widespread use of two-tier architectures.
Figure 34.11. Classic view of a three-tier architecture.
- Interface
windows, reports, and so on. - Application Logic
tasks and rules that govern the process. - Storage
persistent storage mechanism.
Figure 34.12. A three-tier logical division deployed in two physical architectures.
[View full size image]
Related Patterns
- Indirection
layers can add a level of indirection to lower-level services. - Protected Variation
layers can protect against the impact of varying implementations. - Low Coupling and High Cohesion
layers strongly support these goals. - Its application specifically to object-oriented information systems is described in [Fowler96].
Also Known As
The Layers pattern is also known as Layered Architecture [Shaw96, Gemstone00].