Architecture Design Catalog

Architecture Design
Concept Catalog V2.0
for Augmented Attribute-Driven Design (ADD)

Humberto Cervantes (hcm@xanum.uam.mx)
Rick Kazman (kazman@hawaii.edu)

Architecture Design Concept Catalog V2.0
1

Changes

Version Date Summary of changes
1.0 May 2013 Initial version produced for the SATURN tutorial ADD in
the Real World
2.0 February 2014 Added reference architectures and deployment patterns

Table of contents
Introduction ………….………….…………….………….………….………….………. 4
Reference Architectures………….………………….………….………….…………...6
Web Applications………….…………………….………….………….…………...6
Rich Client Applications………….………….………….………….………….…...7
Rich Internet Applications………….………….………….………….……………..9
Mobile Applications………….………………….………….………….……….….11
Service Applications………….…………………….………….………….……….13
Deployment Patterns………….………….………….………….………….………….15
Non-distributed Deployment………….………………….………….…………….15
Distributed Deployment………….…………………….………….………….…...15
Client-server deployment………….…………………….………….………...16
2-Tier deployment………….…………………….………….………….……..16
3-Tier Deployment………….…………………….………….………….…….17
4-Tier Deployment………….…………………….………….………….…....17
Performance Patterns: Load-balanced cluster…………………….…………...18
Reliability Patterns: Failover Cluster………….…………………….…………...18
Security Patterns………….…………………...………….………….…………..19
Impersonation / Delegation…………………….………….………….……..19
Trusted subsystem………….…………………….………….………….…..20
Multiple Trusted Service Identities………….………….………….………..21
Scalability Patterns………….………….………………….………….………….21
Design Patterns………….………….………….…………………….………….…….23
From Mud to Structure (structuring the system)…………………….………...23
Layers………….………….………….…………………….………….……...23
Model View Controller (MVC)………….…………………….………….…..23
Presentation-Abstraction-Control (PAC)…………………….………….….24
Microkernel………….………….………….………….………….…………..25
Pipes and Filters………….………….…………………….………….……..26
Domain Object………….………….………….………….………….……….26
Distribution infrastructure………….………….………….………….…………...27
Messaging………….………….………….………….………….…………...27
Publisher-Subscriber………….………….………….………….…………...28
Broker………….………….………….………….………….………….……..29
Interface Partitioning………….………….………….………….………….……..30

2

Explicit Interface…………………….………….………….…….………….30
Proxy………….………….…………….………….………….…….……….30
Concurrency………….………….……………….………….………….……….31
Half-Sync/Half-Async………….……………….………….……………….31
Leader-Followers………….……………….………….………….…..…….32
Object interaction………….………….…………………….………….………..33
Observer………….………….…………………….………….………….….33
Command………….………….…………………….………….…………...34
Data Transfer Object………….…………………….………….…………..35
Resource Management………….…………………….………….…………....35
Lazy Acquisition………….………….…………………….………….…...35
Database Access………….………….…………………….………….……....36
Database Access Layer………….…………………….………….……...36
Data Mapper (aka Data Access Object - DAO)…………………….…..37
Tactics………….………….………….………….…………………….………….…39
Availability Tactics………….………….………….…………………….……...39
Interoperability Tactics………….………….…………………….…………....41
Modifiability Tactics………….………….…………………….………….…….42
Performance Tactics………….………….…………………….……………....43
Security Tactics………….………….………….………………….……….…..44
Testability Tactics………….………….………….………………….………...45
Usability Tactics………….………….………….………….……………….….47
Frameworks………….………….………….………….………….……………..….48
Structuring the system + supporting quality concerns………………….….48
Spring framework………….………….………….………………….…….48
User interface………….………….………….………….………………….….49
Java Server Faces framework………….………….……………………..49
Swing Framework………….………….………….……………………....50
OO-Relational Mapping………….………….………….……………………..51
Hibernate Framework………….………….………….…………………..51
MyBatis Framework………….………….………….…………………....52
Remote communication………….………….………….…………………….53
RMI Application Programming Interface………….…………………….53
Axis2 Web Services Framework………….………….………………....54
JMS Framework………….………….………….…………………….…..55
Deployment………….………….………….………….…………………...….56
Java Web Start Framework………….………….……………………....56

3

Introduction
This catalog lists several types of design concepts that are to be used in the design of a software
architecture. These design concepts are primitives or building blocks that include:
● Reference Architectures
● Deployment Patterns
● Architectural design patterns
● Architectural Tactics
● Frameworks.

The different types of design concepts are used at different moments of the design process. A suggested
roadmap for their use in the development of a greenfield system is shown in figure 1.

Figure 1. Suggested roadmap for the use of design concepts along different moments of architectural design

In this suggested roadmap, Reference Architectures and Deployment Patterns are initially used to establish
an overall structure for the system. Once this overall structure has been established, functional modules
(Domain Objects) within the reference architecture are identified to support the system’s functionality. These
modules are useful for work assignment and estimation purposes. Later in the design process, other design
concepts including architectural patterns, tactics and frameworks are used to refine the initial design to
support the quality attributes associated to the system under development.

When designing an architecture using the Attribute Driven Design Method, one or more of these design
concepts must be selected in step 4 to satisfy the architectural drivers or architectural issues that are being
addressed in a particular iteration:

4

Figure. Process steps for Augmented Attribute Driven Design (ADD)

The selection of the design concepts in step 4 and the way these design concepts are “instantiated”, that is
adjusted to the design being created, are design decisions that need to be recorded.

The design concepts that are presented in this catalog are taken from various sources including:
● Microsoft, Application Architecture Guide, 2nd Edition - Octobre 2009
● Bass, L., Clements, P., Kazman, R., Software Architecture In Practice, 3d Edition, 2012
● Buschmann, F., Henney, K., Schmidt, D. Pattern-Oriented Software Architecture, Volume 4, Wiley,
2007

5

Reference Architectures
Reference architectures provide a blueprint for structuring an application. This section is a summary from the
Microsoft Application Architecture Guide.
Web Applications

A Web application is an application that can be accessed by the users through a Web browser or a
specialized user agent. The browser creates HTTP requests for specific URLs that map to resources on a
Web server. The server renders and returns HTML pages to the client, which the browser can display. The
core of a Web application is its server-side logic. The application can contain several distinct layers. The
typical example is a three-layered architecture comprised of presentation, business, and data layers. The
Figure illustrates a typical Web application architecture with common components grouped by different
areas of concern. The presentation layer usually includes UI and presentation logic components;; the
business layer usually includes business logic, business workflow and business entities components, and
optionally a façade;; and the data layer usually includes data access and service agent components.

6

Summary Applications of this type typically support connected scenarios and can support
different browsers running on a range of operating systems and platforms.
Benefits Broad reach and a standards-based UI across multiple platforms.

Ease of deployment and change management.
Considerations Dependent on continual network connectivity.

Difficult to provide a rich user interface.

Rich Client Applications

Rich client UIs can provide high performance, interactive, and rich user experiences for applications that
must operate in stand-alone, connected, occasionally connected, and disconnected scenarios. Windows
Forms, Windows Presentation Foundation (WPF), and Microsoft Office Business Application (OBA)
development environments and tools are available that allow developers to quickly and easily build rich client

7

applications.

While these technologies can be used to create stand-alone applications, they can also be used to create
applications that run on the client machine but communicate with services exposed by other layers (both
logical and physical) and other applications that expose operations the client requires. These operations
may include data access, information retrieval, searching, sending information to other systems, back up,
and related activities. Figure shows an overall view of typical rich client architecture, and identifies the
components usually found in each layer.

A typical rich client application is decomposed into three layers: the presentation layer, business layer and
data layer. The presentation layer usually contains UI and presentation logic components;; the business
layer usually contains business logic, business workflow and business entity components;; and the data
layer usually contains data access and service agent components.

Rich client applications may be fairly thin applications consisting of mainly a presentation layer, which
access a remote business layer hosted on server machines through services. An example of this is a data
entry application that sends all of the data to the server for processing and storage.

At the other end of the scale, they may be complex applications that perform most of the processing
themselves and only communicate with other services and data stores to consume or send back
information. An example of this is an application such as Microsoft Excel® spreadsheet software that

8

performs complex local tasks, stores state and data locally and only communicates with remote servers to
fetch and update linked data. These types of rich clients may contain their own business layers and data
access layers. The guidelines for the business and data layers in such applications are the same as those
discussed generally for all applications.

Summary Applications of this type are usually developed as stand-alone applications with a
graphical user interface that displays data using a range of controls. Rich client
applications can be designed for disconnected and occasionally connected
scenarios if they need to access remote data or functionality.
Benefits Ability to leverage client resources.

Better responsiveness, rich UI functionality, and improved user experience.
Highly dynamic and responsive interaction.
Support for offline and occasionally connected scenarios.

Considerations Deployment complexity;; however, a range of installation options such as
ClickOnce, Windows Installer, and XCOPY (.NET) or Java Web Start are
available.
Challenging to version over time.
Platform specific.

Rich Internet Applications

RIAs support rich graphics and streaming media scenarios, while providing most of the deployment and
maintainability benefits of a Web application. RIAs may run inside a browser plug-in, such as Microsoft®
Silverlight®, as opposed to extensions that utilize browser code, such as Asynchronous JavaScript and
XML (AJAX). A typical RIA implementation utilizes a Web infrastructure combined with a client-side
application that handles the presentation. The plug-in provides library routines for rich graphics support as
well as a container that limits access to local resources for security purposes. RIAs have the ability to run
more extensive and complex client-side code than possible in a normal Web application, thus providing the
opportunity to reduce the load on the Web server.

9

A typical Rich Internet Application is decomposed into three layers: the presentation layer, business layer,
and data layer. The presentation layer usually contains UI and presentation logic components;; the business
layer usually contains business logic, business workflow and business entities components;; the data layer
usually contains data access and service agent components. It is common in RIAs to move some of
business processing and even the data access code to the client. Therefore, the client may in fact contain
some or all of the functionality of the business and data layers, depending on the application scenario.

RIAs can range from thin interfaces that overlay back end business services, to complex applications that
perform most of the processes themselves and only communicate with back end services to consume or
send back information. Therefore, the design and implementation varies. However, in terms of the
presentation layer and the way that it communicates with back end services, there are some common
approaches to good architectural design. Most of these are based on well-known design patterns that
encourage the use of separate components within the application to reduce dependencies, make
maintenance and testing easier, and promote reusability.

10

Summary Applications of this type can be developed to support multiple platforms and
multiple browsers, displaying rich media or graphical content. Rich Internet
applications run in a browser sandbox that restricts access to some features of
the client.
Benefits The same rich user interface capability as rich clients.
Support for rich and streaming media and graphical display.
Simple deployment with the same distribution capabilities (reach) as Web clients.
Simple upgrade and version updating.
Cross-platform and cross-browser support.
Considerations Larger application footprint on the client compared to a Web application.
Restrictions on leveraging client resources compared to a rich client application.
Requires deployment of a suitable runtime framework on the client.

Mobile Applications
A mobile application will normally be structured as a multilayered application consisting of presentation,
business, and data layers. When developing a mobile application, you may choose to develop a thin
Web-based client or a rich client. If you are building a rich client, the business and data services layers are
likely to be located on the device itself. If you are building a thin client, all of the layers will be located on the
server. Figure illustrates common rich client mobile application architecture with components grouped by
areas of concern.

11

A mobile application generally contains user interface components in the presentation layer, and perhaps
may include presentation logic components. The business layer, if it exists, will usually contain business
logic components, any business workflow and business entity components that are required by the
application, and, optionally, a façade. The data layer will usually include data access and service agent
components. In order to minimize the footprint on the device, mobile applications generally use less rigid
layering approaches and fewer discrete components.

Summary Applications of this type can be developed as thin client or rich client applications.
Rich client mobile applications can support disconnected or occasionally
connected scenarios. Web or thin client applications support connected
scenarios only. Device resources may prove to be a constraint when designing
mobile applications.
Benefits Support for handheld devices.

Availability and ease of use for out of office users.
Support for offline and occasionally-connected scenarios.

12

Considerations Input and navigation limitations.

Limited screen display area.

Service Applications
A service is a public interface that provides access to a unit of functionality. Services literally provide some
programmatic service to the caller, who consumes the service. Services are loosely coupled and can be
combined within a client, or combined within other services, to provide functionality that is more complex.
Services are distributable and can be accessed from a remote machine as well as from the machine on
which they are running. Services are message-oriented, meaning that service interfaces are defined by a
Web Services Description Language (WSDL) file, and operations are called using Extensible Markup
Language (XML)-based message schemas that are passed over a transport channel. Services support a
heterogeneous environment by focusing interoperability at the message/interface definition. If components
can understand the message and interface definition, they can use the service regardless of their base
technology.

A typical services application is composed of three layers: the service layer, business layer, and data layer.
The service layer may include service interfaces, message types, and data types components;; the business

13

layer may include business logic, business workflow, and business entity components;; and the data layer
may include data access and service agent components

Summary Services expose shared business functionality and allow clients to access them
from a local or a remote system. Service operations are called using messages,
based on XML schemas, passed over a transport channel. The goal of this type of
application is to achieve loose coupling between the client and the server.
Benefits Loosely coupled interactions between client and server.

Can be consumed by different and unrelated applications.
Support for interoperability.
Considerations No UI support.

Dependent on network connectivity.

14

Deployment Patterns
Deployment patterns provide guidance on how to structure the system from a physical standpoint. Good
decision with respect to the deployment of the software system are essential to achieve quality attributes.
This section is a summary from the Microsoft Application Architecture Guide.
Non-distributed Deployment
In a non-distributed deployment, all of the functionality and layers reside on a single server except for data
storage functionality.

This approach has the advantage of simplicity and minimizes the number of physical servers required. It also
minimizes the performance impact inherent when communication between layers must cross physical
boundaries between servers or server clusters. Keep in mind that by using a single server, even though you
minimize communication performance overhead, you can hamper performance in other ways. Because all of
your layers share resources, one layer can negatively affect all of the other layers when it is under heavy
utilization. In addition, the servers must be generically configured and designed around the strictest of
operational requirements, and must support the peak usage of the largest consumers of system resources.
The use of a single tier reduces your overall scalability and maintainability because all the layers share the
same physical hardware.
Distributed Deployment
In a distributed deployment, the layers of the application reside on separate physical tiers. Tiered
distribution organizes the system infrastructure into a set of physical tiers to provide specific server
environments optimized for specific operational requirements and system resource usage. It allows you to
separate the layers of an application on different physical tiers.

15

A distributed approach allows you to configure the application servers that host the various layers in order to
best meet the requirements of each layer. However, because the primary driver for optimizing component
deployment is to match a component's resource consumption profile to an appropriate server, this implies
that a direct mapping of layers to tiers is often not the ideal distribution strategy.
Multiple tiers enable multiple environments. You can optimize each environment for a specific set of
operational requirements and system resource usage. You can then deploy components onto the tier that
most closely matches their resource needs to maximize operational performance and behavior. The more
tiers you use, the more deployment options you have for each component. Distributed deployment provides
a more flexible environment where you can more easily scale out or scale up each physical tier as
performance limitations arise, and when processing demands increase. However, keep in mind that adding
more tiers adds complexity, deployment effort, and cost.
Another reason for adding tiers is to apply specific security policies. Distributed deployment allows you to
apply more stringent security to the application servers;; for example, by adding a firewall between the Web
server and the application servers, and by using different authentication and authorization options.

Client-server deployment
This pattern represents a basic structure with two main components: a client and a server. In this scenario,
the client and server will usually be located on two separate tiers. The following Figure represents a common
Web application scenario where the client interacts with a Web server. Consider the client/server pattern if
you are developing a client that will access an application server, or a stand-alone client that will access a
separate database server.

2-Tier deployment
Effectively this is the same physical layout as the client/server pattern. It differs mainly on the ways that the
components on the tiers communicate. In some cases, as shown in the following Figure, all of the
application code is located on the client, and the database is located on a separate server. The client
makes use of stored procedures or minimal data access functionality on the database server. Consider the
2-tier pattern if you are developing a client that will access an application server, or a stand-alone client that
will access a separate database server.

16

3-Tier Deployment
In a 3-tier design, the client interacts with application software deployed on a separate server, and the
application server interacts with a database that is located on another server, as shown in the following
Figure. This is a very common pattern for most Web applications and Web services, and sufficient for most
general scenarios. You might implement a firewall between the client and the Web/App tier, and another
firewall between the Web/App tier and the database tier. Consider the 3-tier pattern if you are developing an
Intranet-based application where all servers are located within the private network or an Internet based
application and security requirements do not prevent you from implementing business logic on the public
facing Web or application server.

4-Tier Deployment
In this scenario, shown in the following Figure, the Web server is physically separated from the application
server. This is often done for security reasons, where the Web server is deployed into a perimeter network
and accesses the application server located on a different subnet. In this scenario, you might implement a
firewall between the client and the Web tier, and another firewall between the Web tier and the application or
business logic tier. Consider the 4-tier pattern if security requirements dictate that business logic cannot be
deployed to the perimeter network, or you have application code that makes heavy use of resources on the
server and you want to offload that functionality to another server.

17

Performance Patterns: Load-balanced cluster

You can install your service or application onto multiple servers that are configured to share the workload.

Load balancing scales the performance of server-based programs, such as a Web server, by distributing
client requests across multiple servers. Load-balancing technologies, commonly referred to as load
balancers, receive incoming requests and redirect them to a specific host if necessary. The load-balanced
hosts concurrently respond to different client requests, even multiple requests from the same client. For
example, a Web browser might obtain the multiple images within a single Web page from different hosts in
the cluster. This distributes the load, speeds up processing, and reduces the response time.

Reliability Patterns: Failover Cluster

A failover cluster is a set of servers that are configured in such a way that if one server becomes unavailable,
another server automatically takes over for the failed server and continues processing.

18

Install your application or service on multiple servers that are configured to take over for one another when a
failure occurs. The process of one server taking over for a failed server is commonly known as failover. Each
server in the cluster has at least one other server in the cluster identified as its standby server.
Security Patterns
Impersonation / Delegation
The impersonation/delegation approach is a good solution when you must flow the context of the original
caller to downstream layers or components in your application.

19

In the impersonation/delegation authorization model, resources and the types of operations (such as read,
write, and delete) permitted for each one are secured using Access Control Lists (ACLs) or the equivalent
security features of the targeted resource (such as tables and procedures in SQL Server). Users access the
resources using their original identity through impersonation.
Trusted subsystem
In the trusted subsystem (or trusted server) model, users are partitioned into application defined, logical
roles. Members of a particular role share the same privileges within the application. Access to operations
(typically expressed by method calls) is authorized based on the role membership of the caller. With this
role-based (or operations-based) approach to security, access to operations (not networked resources) is
authorized based on the role membership of the caller. Roles, analyzed and defined at application design
time, are used as logical containers that group together users who share the same security privileges or
capabilities within the application. The middle-tier service uses a fixed identity to access downstream
services and resources.

20

Multiple Trusted Service Identities

In some situations, you might require more than one trusted identity. For example, you might have two
groups of users, one who should be authorized to perform read/write operations and the other read-only
operations. The use of multiple trusted service identities provides the ability to exert more granular control
over resource access and auditing, without having a large impact on scalability.

Scalability Patterns
Your approach to scaling is a critical design consideration. Whether you plan to scale out your solution
through a load-balanced cluster or a partitioned database, you must ensure that your design supports the
option you choose. In general cases, when you scale your application, you can choose from and combine
two basic choices: scale up (get a bigger box) and scale out (get more boxes).

With the scale up approach, you add hardware such as processors, RAM, and network interface cards
(NICs) to your existing servers to support increased capacity. This is a simple option and can be
cost-effective up to a certain level because it does not introduce additional maintenance and support costs.
However, any single points of failure remain, which is a risk. In addition, beyond a certain threshold, adding
more hardware to the existing servers may not produce the desired results, and getting the last 10% of
theoretical performance from a single machine though upgrades can be very expensive.

For an application to scale up effectively, the underlying framework, runtime, and computer architecture
must scale up as well. When scaling up, consider which resources are limiting application performance. For
example, if it is memory bound or network bound, adding CPU resources will not help.

With the scale out approach, you add more servers and use load balancing and clustering solutions. In
addition to handling additional load, the scale out scenario also mitigates hardware failures. If one server

21

fails, there are additional servers in the cluster that can take over the load. For example, you might have
multiple load-balanced Web servers in a Web farm that host the presentation and business layers.
Alternatively, you might physically partition your application’s business logic, and use a separate
load-balanced middle tier for that logic while hosting the presentation layer on a load-balanced front tier. If
your application is I/O constrained and you must support an extremely large database, you might partition
your database across multiple database servers. In general, the ability of an application to scale out
depends more on its architecture than on the underlying infrastructure.

22

Architecture Design Catalog

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Architecture Design Catalog

Încărcat de

Drepturi de autor:

Formate disponibile

2.0 February 2014 Added reference architectures and deployment patterns

Benefits Broad reach and a standards-based UI across multiple platforms.

Considerations Dependent on continual network connectivity.

Rich Client Applications

Benefits Ability to leverage client resources.

Rich Internet Applications

Benefits Support for handheld devices.

Considerations Input and navigation limitations.

Benefits Loosely coupled interactions between client and server.

Considerations No UI support.

Performance Patterns: Load-balanced cluster

Reliability Patterns: Failover Cluster

Multiple Trusted Service Identities

S-ar putea să vă placă și

Architecture Design Catalog

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Architecture Design Catalog

Încărcat de

Drepturi de autor:

Formate disponibile

2.0 February 2014 Added reference architectures and deployment patterns

Benefits Broad reach and a standards-­based UI across multiple platforms.

Considerations Dependent on continual network connectivity.

Rich Client Applications

Benefits Ability to leverage client resources.

Rich Internet Applications

Benefits Support for handheld devices.

Considerations Input and navigation limitations.

Benefits Loosely coupled interactions between client and server.

Considerations No UI support.

Performance Patterns: Load-­balanced cluster

Reliability Patterns: Failover Cluster

Multiple Trusted Service Identities

S-ar putea să vă placă și

Benefits Broad reach and a standards-based UI across multiple platforms.

Performance Patterns: Load-balanced cluster