A. A Design Concepts Catalog
This chapter presents an excerpt from a catalog that groups design concepts that are associated with the domain of enterprise applications, such as the one presented in the case study in Chapter 4. As opposed to traditional catalogs that list just a single type of design concept, such as pattern catalogs, the catalog presented here groups different varieties of related design concepts. In this case, the catalog includes a selection of reference architectures, deployment patterns, design patterns, tactics, and externally developed components (frameworks). Also, the design concepts that are included in this catalog are gathered from different sources, reflecting what occurs in real-life design. The design concepts are presented in a very succinct way, and the reader looking for more detail should refer to the original sources using the references provided at the end of the chapter.
A.1 Reference Architectures
Reference architectures provide a blueprint for structuring an application (see Section 2.5.1). This section is based on the catalog in the Microsoft Application Architecture Guide.
A.1.1 Web Applications
This web application is typically initiated from a web browser that communicates with a server using the HTTP protocol. The bulk of the application resides on the server, and its architecture is typically composed of three layers: the presentation, business, and data layers. The presentation layer contains modules that are responsible for managing user interaction. The business layer contains modules that handle aspects related to the business logic. The data layer contains modules that manage data that is stored either locally or remotely. In addition, certain functionality that is common to modules across the layers is organized as cross-cutting concerns. This cross-cutting functionality includes aspects related to security, logging, and exception management. Figure A.1 presents the components associated with the modules in web applications.
The following table summarizes the responsibilities of the components present in this reference architecture:
You should consider using this type of application when:
You do not require a rich user interface.
You do not want to deploy the application by installing anything on the client machine
You require portability of the user interface.
Your application needs to be accessible over the Internet.
You want to use a minimum of client-side resources.
A.1.2 Rich Client Applications
Rich client applications are installed and run on a user’s machine. Because the application runs on the user’s machine, its user interface can provide a high-performance, interactive, and rich user experience. A rich client application may operate in stand-alone, connected, occasionally connected, or disconnected mode. When connected, it typically communicates with remote services provided by other applications.
Rich client application modules are structured in three main layers or in a cross-cutting grouping, similar to a web application (see Section A.1.1). Rich client applications can be “thin” or “thick.” Thin-client applications consist primarily of presentation logic, which obtains user data and sends it to a server for processing. Thick-client applications contain business and data logic and typically connect to a data storage server only to exchange information that needs to be persisted remotely. Figure A.2 presents the components associated with the modules in rich client applications.
You should consider using this type of application when:
You want to deploy your application on the users’ machines.
You want your application to support intermittent or no network connectivity.
You want your application to be highly interactive and responsible.
You want to leverage the user’s machine resources (such as a graphics card).
Since these applications are deployed on the user’s machine, they are less portable and deployment and updating is more complicated. A range of technologies to facilitate their installation are available, however.
A.1.3 Rich Internet Applications
Rich Internet applications (RIAs) typically run inside a browser and may be developed using code that is executed by the browser such as Asynchronous JavaScript and XML (AJAX). RIAs may also run inside a browser plug-in, such as Silverlight. These applications are more complex than standard web applications and support rich user interaction and business logic. They are, however, typically restricted with respect to accessing local resources because of security concerns.
Typical RIAs are structured using the same three layers and modules found in web applications (see Section A.1.1). In RIAs, some business logic may be executed on the client machine, and some data may be stored locally. Like rich client applications, RIAs may range from relatively thin to quite thick clients.
The following table summarizes the responsibilities of the components of this reference architecture (shown in Figure A.3) that are not present in the Web Application reference architecture:
You should consider using this type of application when:
You want your application to have a rich user interface but still run inside a browser.
You want to perform some of the processing on the client side.
You want to deploy and update your application in a simple manner, without having to perform installations on the user machine.
However, there are some limitations associated with this type of application:
Access to local resources can be limited, because the application may run in a sandbox.
Loading time is non-negligible.
Plug-in execution environments may not be available in all platforms.
A.1.4 Mobile Applications
A mobile application is typically executed on a handheld device and usually works in collaboration with a support infrastructure that resides remotely. These applications are structured using modules and layers similar to those found in a web application (see Section A.1.1), although many of the components derived from these modules may be optional depending on whether a thin-client or a thick-client approach is followed. As shown in Figure A.4, at a minimum, the components responsible for user interaction are typically present. Communication with the support infrastructure is frequently unreliable, and these applications normally include some type of local data store that is periodically synchronized with data in the support infrastructure.
You should consider using this type of application when:
You want your application to run in a handheld device.
The network connectivity is unreliable, so the application needs to run in both offline and occasionally connected modes.
However, there is a substantial limitation associated with this type of application:
Resources on the handheld device may be limited.
A.1.5 Service Applications
Service applications are non-interactive applications that expose functionality through public interfaces (i.e., services). Services may be invoked by service consumer components remotely or from the same machine in which the service application is running. Services can be defined using a description language such as the Web Services Description Language (WSDL); operations are invoked using XML-based message schemas that are transferred over a transport channel. As a consequence, services promote interoperability.
Similar to the other types of reference architectures, service applications are structured using layers (Figure A.5). These applications are not interactive, so the presentation layer is not needed. It is replaced by a service layer that contains components responsible for exposing the services and exchanging information, similar to the server part of RIAs (see Section A.1.3).
You should consider using this type of application when:
Your application is not used by humans but rather by other systems and, as a consequence, does not have a user interface.
Your application and the clients should be loosely coupled.
Except in cases where services are consumed by applications that reside in the same machine, network connectivity is required for the clients to communicate with the service application.
A.2 Deployment Patterns
Deployment patterns provide guidance on how to structure the system from a physical standpoint (see Section 2.5.3). Good decisions with respect to the deployment of the software system are essential to achieve important quality attributes such as performance, usability, availability, and security. This section is a summary from the catalog included in the Microsoft Application Architecture Guide.
A.2.1 Nondistributed Deployment
In nondistributed deployment, all of the components from the modules in the different layers reside on a single server except for data storage functionality (Figure A.6). Because the components communicate locally, this may improve performance due to the lack of network communication delays. However, performance may be affected by other aspects of the system, such as resource contention. Also, this type of application must support the peak usage of the largest consumers of system resources. Scalability and maintainability may be negatively affected because the same physical hardware is shared by all of the components.
A.2.2 Distributed Deployment
In a distributed deployment, the components of the application reside on separate physical tiers (Figure A.7). Typically, the components associated with specific layers are deployed in different tiers. Tiers can be configured differently to best meet the requirements of the components that it hosts.
Distributed deployment facilitates scalability but the addition of tiers also brings additional costs, network latency, complexity, and deployment effort. More tiers may also be added to promote security. Different security policies may be applied according to the particular tier, and firewalls may be placed between the tiers. The following subsections describe various alternatives of distributed deployment that can be used in conjunction with the reference architectures from Section A.1.
Two-Tier Deployment (Client-Server)
Two-tier deployment is the most basic layout for distributed deployment. The client and the server are usually deployed on different physical tiers, as shown in Figure A.8.
Three-Tier Deployment
In three-tier deployment, the application is deployed in a tier that is separate from the one that hosts the database, as shown in Figure A.9. This is a very common physical layout for web applications.
Four-Tier Deployment
In four-tier deployment, shown in Figure A.10, the web server and the application server are deployed in different tiers. This separation is usually done to improve security, as the web server may reside in a publicly accessible network while the application resides in a protected network. Additionally, firewalls may be placed between the tiers.
A.2.3 Performance Patterns: Load-Balanced Cluster
In the Load-Balanced Cluster pattern, the application is deployed on multiple servers that share the workload, as shown in Figure A.11. Client requests are received by a load balancer, which redirects them to the various servers according to their current load. The different application servers can process several requests concurrently, which results in performance improvements.
A.3 Architectural Design Patterns
This section includes architectural design patterns (see Section 2.5.2) used in the case study in Chapter 4. The patterns presented here are based on the book Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing, Volume 4. The numbers in parentheses [e.g., Domain Model (182)] indicate the page in the book where the pattern is documented.
Note that we are using a home-grown notation for the patterns here, which is common in the patterns community. We define the symbols in a legend accompanying the first diagram (Layers) and use these symbols throughout this section.
A.3.1 Structural Patterns
These patterns are used to structure the system but they provide less detail than the reference architectures.
A.3.2 Interface Partitioning
A.4 Tactics
Tactics were presented in Section 2.5.4. Here we present a summarized catalog of tactics for seven commonly encountered quality attributes. This catalog comes from the book Software Architecture in Practice.
A.4.1 Availability Tactics
Figure A.12 summarizes the tactics to achieve availability.
Detect Faults
Ping/echo: An asynchronous request/response message pair exchanged between nodes is used to determine reachability and the round-trip delay through the associated network path.
Monitor: A component is used to monitor the state of health of other parts of the system. A system monitor can detect failure or congestion in the network or other shared resources, such as from a denial-of-service attack.
Heartbeat: A periodic message exchange occurs between a system monitor and a process being monitored.
Timestamp: Detect incorrect sequences of events, primarily in distributed message-passing systems.
Sanity checking: Check the validity or reasonableness of a component’s operations or outputs; typically based on a knowledge of the internal design, the state of the system, or the nature of the information under scrutiny.
Condition monitoring: Check conditions in a process or device, or validates assumptions made during the design.
Voting: Check that replicated components are producing the same results. Comes in various flavors, such as replication, functional redundancy, analytic redundancy.
Exception detection: Detect a system condition that alters the normal flow of execution, such as a system exception, parameter fence, parameter typing, or timeout.
Self-test: Procedure for a component to test itself for correct operation.
Recover from Faults (Preparation and Repair)
Active redundancy (hot spare): All nodes in a protection group receive and process identical inputs in parallel, allowing redundant spare(s) to maintain synchronous state with the active node(s).
Passive redundancy (warm spare): Only the active members of the protection group process input traffic; one of their duties is to provide the redundant spare(s) with periodic state updates.
Spare (cold spare): Redundant spares of a protection group remain out of service until a failover occurs, at which point a power-on-reset procedure is initiated on the redundant spare prior to its being placed in service.
Exception handling: Deal with the exception by reporting it or handling it, potentially masking the fault by correcting the cause of the exception and retrying.
Rollback: Revert to a previous known good state, referred to as the “rollback line.”
Software upgrade: Perform in-service upgrades to executable code images in a non-service-affecting manner.
Retry: When a failure is transient, retrying the operation may lead to success.
Ignore faulty behavior: Ignore messages sent from a source when it is determined that those messages are spurious.
Degradation: Maintain the most critical system functions in the presence of component failures, dropping less critical functions.
Reconfiguration: Reassign responsibilities to the resources that continue to function, while maintaining as much functionality as possible.
Recover from Faults (Reintroduction)
Shadow: Operate a previously failed or in-service upgraded component in a “shadow mode” for a predefined time prior to reverting the component back to an active role.
State resynchronization: Passive redundancy; state information is sent from active to standby components, in this partner tactic to active redundancy.
Escalating restart: Recover from faults by varying the granularity of the component(s) restarted and minimizing the level of service affected.
Non-stop forwarding: Functionality is split into supervisory and data variants. If a supervisor fails, a router continues forwarding packets along known routes while protocol information is recovered and validated.
Prevent Faults
Removal from service: Temporarily place a system component in an out-of-service state for the purpose of mitigating potential system failures.
Transactions: Bundle state updates so that asynchronous messages exchanged between distributed components are atomic, consistent, isolated, and durable.
Predictive model: Monitor the state of health of a process to ensure that the system is operating within nominal parameters; take corrective action when conditions are detected that are predictive of likely future faults.
Exception prevention: Prevent system exceptions from occurring by masking a fault, or prevent them via smart pointers, abstract data types, and wrappers.
Increase competence set: Design a component to handle more cases—faults—as part of its normal operation.
A.4.2 Interoperability Tactics
Figure A.13 summarizes the tactics to achieve interoperability.
Locate
Discover service: Locate a service by searching a known directory service. There may be multiple levels of indirection in this location process—that is, a known location may point to another location that in turn can be searched for the service.
Manage Interfaces
Orchestrate: Use a control mechanism to coordinate, manage, and sequence the invocation of services. Orchestration is used when systems must interact in a complex fashion to accomplish a complex task.
Tailor interface: Add or remove capabilities to an interface such as translation, buffering, or data smoothing.
A.4.3 Modifiability Tactics
Figure A.14 summarizes the tactics to achieve modifiability.
Reduce Size of a Module
Split module: If the module being modified includes a great deal of capability, the modification costs will likely be high. Refining the module into several smaller modules should reduce the average cost of future changes.
Increase Cohesion
Increase semantic coherence: If the responsibilities A and B in a module do not serve the same purpose, they should be placed in different modules. This may involve creating a new module or moving a responsibility to an existing module.
Reduce Coupling
Encapsulate: Encapsulation introduces an explicit interface to a module. This interface includes an API and its associated responsibilities, such as “perform a syntactic transformation on an input parameter to an internal representation.”
Use an intermediary: Given a dependency between responsibility A and responsibility B (for example, carrying out A first requires carrying out B), the dependency can be broken by using an intermediary.
Restrict dependencies: Restrict the modules that a given module interacts with or depends on.
Refactor: Refactoring is undertaken when two modules are affected by the same change because they are (at least partial) duplicates of each other.
Abstract common services: When two modules provide not quite the same but similar services, it may be cost-effective to implement the services just once in a more general (abstract) form.
Defer Binding
Defer binding: Allow decisions to be bound after development time.
A.4.4 Performance Tactics
Figure A.15 summarizes the tactics to achieve performance.
Control Resource Demand
Manage sampling rate: If it is possible to reduce the sampling frequency at which a stream of data is captured, then demand can be reduced, albeit typically with some loss of fidelity.
Limit event response: Process events only up to a set maximum rate, thereby ensuring more predictable processing when the events are actually processed.
Prioritize events: If not all events are equally important, you can impose a priority scheme that ranks events according to how important it is to service them.
Reduce overhead: The use of intermediaries (important for modifiability) increases the resources consumed in processing an event stream; removing them improves latency.
Bound execution times: Place a limit on how much execution time is used to respond to an event.
Increase resource efficiency: Improving the algorithms used in critical areas will decrease latency.
Manage Resources
Increase resources: Faster processors, additional processors, additional memory, and faster networks all have the potential to reduce latency.
Increase concurrency: If requests can be processed in parallel, the blocked time can be reduced. Concurrency can be introduced by processing different streams of events on different threads or by creating additional threads to process different sets of activities.
Maintain multiple copies of computations: The purpose of replicas is to reduce the contention that would occur if all computations took place on a single server.
Maintain multiple copies of data: Keep copies of data (with one potentially being a subset of the other) on storage with different access speeds.
Bound queue sizes: Control the maximum number of queued arrivals and consequently the resources used to process the arrivals.
Schedule resources: When there is contention for a resource, the resource must be scheduled.
A.4.5 Security Tactics
Figure A.16 summarizes the tactics to achieve security.
Detect Attacks
Detect intrusion: Compare network traffic or service request patterns within a system to a set of signatures or known patterns of malicious behavior stored in a database.
Detect service denial: Compare the pattern or signature of network traffic coming into a system to historic profiles of known denial-of-service attacks.
Verify message integrity: Use techniques such as checksums or hash values to verify the integrity of messages, resource files, deployment files, and configuration files.
Detect message delay: By checking the time that it takes to deliver a message, it is possible to detect suspicious timing behavior.
Resist Attacks
Identify actors: Identify the source of any external input to the system.
Authenticate actors: Ensure that an actor (user or a remote computer) is actually who or what it purports to be.
Authorize actors: Ensure that an authenticated actor has the rights to access and modify either data or services.
Limit access: Control what and who may access which parts of a system, such as processors, memory, and network connections.
Limit exposure: Reduce the probability of a successful attack, or restrict the amount of potential damage—for example, by concealing facts about a system (“security by obscurity”) or by dividing and distributing critical resources (“don’t put all your eggs in one basket”).
Encrypt data: Apply some form of encryption to data and to communication.
Validate input: Validate input from a user or an external system before accepting it in the system.
Separate entities: Use physical separation on different servers attached to different networks, virtual machines, or an “air gap.”
Change default settings: Force the user to change settings assigned by default.
React to Attacks
Revoke access: Limit access to sensitive resources, even for normally legitimate users and uses, if an attack is suspected.
Lock computer: Limit access to a resource if there are repeated failed attempts to access it.
Inform actors: Notify operators, other personnel, or cooperating systems when an attack is suspected or detected.
Recover from Attacks
In addition to the availability tactics for recovery of failed resources, an audit may be performed to recover from attacks.
Maintain Audit Trail: Keep a record of user and system actions and their effects, to help trace the actions of, and to identify, an attacker.
A.4.6 Testability Tactics
Figure A.17 summarizes the tactics to achieve testability.
Control and Observe System State
Specialized interfaces: Control or capture variable values for a component either through a test harness or through normal execution.
Record/playback: Capture information crossing an interface and use it as input for further testing.
Localize state storage: To start a system, subsystem, or module in an arbitrary state for a test, it is most convenient if that state is stored in a single place.
Abstract data sources: Abstracting the interfaces lets you substitute test data more easily.
Sandbox: Isolate the system from the real world to enable experimentation that is unconstrained by the worry about having to undo the consequences of the experiment.
Executable assertions: Assertions are (usually) hand-coded and placed at desired locations to indicate when and where a program is in a faulty state.
Limit Complexity
Limit structural complexity: Avoid or resolve cyclic dependencies between components, isolate and encapsulate dependencies on the external environment, and reduce dependencies between components in general.
Limit nondeterminism: Find all the sources of non-determinism, such as unconstrained parallelism, and weed them out as far as possible.
A.4.7 Usability Tactics
Figure A.18 summarizes the tactics to achieve usability.
Support User Initiative
Cancel: The system must listen for the cancel request; the command being canceled must be terminated; resources used must be freed; and collaborating components must be informed.
Pause/resume: Temporarily free resources so that they may be reallocated to other tasks.
Undo: Maintain a sufficient amount of information about system state so that an earlier state may be restored at the user’s request.
Aggregate: Aggregate lower-level objects into a group, so that a user operation may be applied to the group, freeing the user from the drudgery.
Support System Initiative
Maintain task model: Determine the context so the system can have some idea of what the user is attempting and provide assistance.
Maintain user model: Explicitly represent the user’s knowledge of the system, the user’s behavior in terms of expected response time, and other characteristics of the system.
Maintain system model: The system maintains an explicit model of itself. This tactic is used to determine expected system behavior so that appropriate feedback can be given to the user.
A.5 Externally Developed Components
Externally developed components, including frameworks, were discussed in Section 2.5.5. Here we present a small sample of Java frameworks used in the case study in Chapter 4. Each framework is described very briefly and is associated with particular technology families, patterns, and tactics. Full details for the different frameworks can be found by visiting the URL that is provided.
A.5.1 Spring Framework
A.5.4 Java Web Start Framework
A.6 Summary
In this appendix we presented a design concepts catalog for the application domain of enterprise applications. Catalogs such as this one can become useful organizational assets, and we can readily imagine catalogs for other application domains such as Big Data (which we employ in Chapter 5) or mobile development.
The catalog presented here is not intended to be exhaustive, as it contains only the design concepts used in the Chapter 4 case study. A real catalog, however, would contain a larger number of design concepts with more detailed descriptions and would be a valuable asset in a software development organization.
A.7 Further Reading
Reference architectures and deployment patterns are taken from Microsoft, Application Architecture Guide (2nd ed.), October 2009.
The tactics catalog is derived primarily from L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice (3rd ed.), 2012. Some of these tactics were earlier described in: F. Bachmann, L. Bass, and R. Nord, “Modifiability Tactics”, SEI/CMU Technical Report CMU/SEI-2007-TR-002, 2007, and J. Scott and R. Kazman, “Realizing and Refining Architectural Tactics: Availability”, CMU/SEI-2009-TR-006, 2009.
The architectural patterns are taken from R. Buschmann, K. Henney, and D. Schmidt, Pattern-Oriented Software Architecture, Volume 4, Wiley, 2007.
The Spring framework is discussed in C. Walls, Spring in Action (4th ed.), Manning Publications, 2014.
The Swing framework is discussed in J. Elliot, R. Eckstein, D. Wood, and B. Cole, Java Swing (2nd ed.), O’Reilly Media, 2002.
The Hibernate framework is discussed in C. Bauer and G. King, Java Persistence with Hibernate, Manning Publications, 2015.