SOA Patterns Selection and Application based on
Software Quality Requirements
Heng Zhao Xiuhong Chen, Wenqian Zhang,
Wuhan Digital Engineering Institute Peng Liang, Jian Wang
Wuhan, China School a/Computer Sc ience
hellezhao@126.com Wuhan University
{chenxh,wqzhang,liangp,jianwang}
@whu.edu.cn
Abstract-Applying software architecture patterns in SOA
architecture design is an important way to construct high quality
design of softwa re architecture. Meanwhil e, t he selection of
architecture patterns has a close relationship to quality
requirement s of softwa re systems to be developed. Applying a
speeiflc architecture pattern can usually a ddr ess specific quality
requirement s, and further optimize architecture design. In tin s
pap er, we fir st mad e a comprehen sive survey and analysis on th e
ty pe of quality re quire ments, and refined twenty-one quality
requirement s that are frequently used in softwa re architecture
design. W e then classified th e SOA patterns in th e perspective of
quality requirements, which can help architects select
appropriate SOA patterns according to the quality r equirement s
of their system. Finally, we illustrat ed the proposed method by
selecting a specitlc SOA pattern t o design an onlin e book
distribution management system.
Keywords-Softw are Quality Requirement; So/Mare
Architecture Pattern; SOA; SOA Pattern
1. I NTR ODUCTION
Software architecture design is the initial blueprint for
the design of software systems, relying primarily on the
functional requirements and quality requirements (i.e., non-
functional requirements) of software systems. Compared to
software architecture design that meets functional
requirements, architecture design for addressing quality
requirements is often the most difficult and easily overlooked
by software architects during the design process. Meanwhile,
software architecture design as a knowledge-intensive activity,
the satisfaction of system quality requirements in architecture
design largely depends on the personal knowledge and
experience of software architects, and lacks of a systematic
design method. Software architecture patterns provide
architecture design knowledge that has been proved to be
effective and reusable in practice for architecture design,
which can effectively improve the efficiency and quality of
architecture design. A large number of software architecture
patterns have been widely used in industry [3], including
Service Oriented Architecture (SOA) design patterns [4].
SOA is a special kind of software architecture and also a
component model, with which various functional units (i.e.,
services) of an application are connected through well-defined
interfaces and contracts between these services [1]. The
interfaces are defined in a neutral way, which means that they
978-1-5386-65 65-7/18/$3 1.00 (f)2018 IEEE
361
Wei Huang
Wuhan Digital Engineering Institute
Wuhan . China
huangweinet@sina.com
are independent of hardware platforms, operating systems, and
programming languages that implement these services. This
enables the built services to interact with each other in a
unified and universal way in such a system. With the loosely
coupled nature, SOA can utilize the existing applications to
provide new services through composition in an agile and
flexible way for the enterprise to build new applications and
business processes. These features of SOA make the systems
more maintainab le and usable with better scalability. As a new
style of software architecture, SOA has received an increasing
attention in both academia and industry [2].
With the wide application of SOA in the architecture
design of software systems, many SOA patterns [4] are also
emerged in the design. However, it is difficult and challenging
for architects who lack design experience (such as a novice
architect) to select suitable SOA patterns for addressing the
quality requirements of the system. Therefore, in SOA design,
to recommend suitable SOA patterns based on the quality
requirements of the system to architects for their consideration
and selection, has becoming a meaningful and practical
research topic, which can facilitate systematic SOA design and
reuse of SOA patterns.
As a design method of building software systems, SOA
can guide the whole life cycle of software design. With the
wide adoption of SOA, users have been increasingly
concerned about non-functional requirements of the system [5]
while the function requirements are met. In [4], Thomas et al.
summarized 85 commonly used SOA patterns that can be used
to achieve business goals related to service oriented
computing with the purpose of developing and delivering high
quality SOA-based software systems. These SOA patterns are
the collection of existing design knowledge that satisfies
various quality requirements, but how to apply these SOA
patterns according to the quality requirements of the system is
still a challenge for architects, which is the problem we try to
tackle in this work.
In this work, we first made a comprehensive survey and
analysis of the types of software quality requirements based on
the existing literature. The twenty-one quality requirements
commonly considered in architecture design are presented in
Section 1. The background information of software quality
requirements and software architecture patterns is described in
Section II. In Section III, aiming at several commonly used
quality requirements, we classified the SOA patterns in [4] in
order to assist architects in selecting appropriate SOA patterns
according to the quality requirements. In Section IV, we used
the recommended SOA patterns to meet the specific quality
requirements and show the effectiveness of the method
through an example of the architecture design of an online
book distributio n management system. Section V summarizes
the work with future directions .
II . BACKGROUND
A . Quality Requirements Classification
Software quality requirements are often used to specify
the qua lity attributes of software systems beyond the
functional requirements of software systems, such as
performance, reliability, and scalability. In [6], Ozkaya et al.
described in detai l what software quality attributes are and
presented the use of quality attributes in software
architecture design . In [7], Berntsson et al . systematically
investigated the quality attributes commonly considered in
industrial software development projects. Both the ISO
25010 standard [8] and [9] provide the classification and
definition of software quality requirements. In this work, we
combined the definitions of software quality requirements
from these two references ([8][9]) and gave a clear
definition for the quality requirements that have similar
definitions. Meanwhile, we distinguished different quality
requirements with the description of the quality attributes in
[10, 11]. Finally twe nty-one quality requirements (see
TABLE I) were extracted whic h are commonly considered
in architecture design. Some of the quality requirements are
sub -requirements or similar requirements of other quality
requirements, such as Fault Tolerance is part of Robustness.
TABLE 1. SOFTWARE QUALITY REQUIREMENTS COMMONLY
CONSIDERED IN SOFTWARE ARCHITECTURE DESIGN
Qua lity
Requireme nts
Descr iptio u
Usability The characteristics of a product for a
particu lar use in a certain environment,
including effectiveness, efficiency, and
user satisfaction.
Performance System response time, efficiency of task
execution [9].
Reliability The frequency interval of the system failure
(mean time between failures) and the
proportion of time when the system is
availab le.
Stability The probability of an error or the trend of
performance degradation during operation
of the software system .
Flexibility The easiness with which the system can be
extended with new features, including
Changeabi lity.
Security How the system handles physical barriers
and prevents malicious attacks on the
system [9].
Compliance Whether the system can meet the domain or
technical standards [8].
Maintainability Whether the errors of the system can be
362
located and fixed [9].
Reusability Whether the modules of the system can be
easily reused in other systems [9].
Interoperabi lity Whether the system can easily interact with
other systems, such as transferring files to
spreadsheets or accessing new hardware
units [9].
Recoverability The ability of the system to recover from
faults, errors, and malfunctions [8].
Correctn ess Under a normal operation, the system can
produce correct results.
Testability The easiness of the system to be tested after
the system changes [9].
Portability The easiness of the system to be
transplanted to a new software or hardware
platform [9], including Adaptability.
Suitability Whether the system can fully support the
tasks of the users [8].
Analyzability The capability of software products to be
diagnosed as deficiencies and the cause of
errors, or to identify the parts that need to
be modified [8].
Rep laceability The extent to which the system or part of
the system can be replaced.
Understandability The easiness with which developers can
understand the architecture design .
Operability The easiness of the software product to be
operated and controlled by the users .
Robustness The extent to which a system or component
can be operated norma lly under an invalid
input or pressure environment [11],
including Fault Tolerance.
Scalability As the system functio ns or load increase,
the capability of the system to keep normal
response time or throughput.
B . Software Architecture Patterns
A software architecture pattern is a reusable solution to a
specific architecture design problem in a given environment. It
represents the basic structured organization of the software
system. It provides a set of predefined subsystems, and defines
their responsibilities with constraint rules and application
guidelines for organizing relationships between the subsystems
[12]. Software architecture patterns as reusable architecture
design solutions for specific design problems in a given
environment, i.e., the relationships between structural elements
in the definition of software architecture given in [13],
architecture patterns are usually used to satisfy several
functional requirements and quality requirements of the system
in architecture design.
III . SOAPATTERNS SELECTION
A . SOA Patterns
The fundamental objective of SOA patterns is to develop
and deliver high-quality software systems, which summarize
the design patterns commonly used in SOA-based systems in
order to achieve business goals related to service-oriented
computing [4]. The intention of SOA patterns is not to replace
or compete with existing design and architecture patterns, but
to build and supplement existing design patterns used in
software systems. These SOA patterns focus on strategic goals
related to service-oriented computing, including new patterns,
existing patterns that are extended, and patterns that are similar
to the intent of other patterns . SOA patterns are designed to
allow the original patterns to be interpreted in the context of
SOA design and to highlight SOA patterns as a supporting part
of the service-oriented design paradigm . Understanding the
underlying design solutions and techniques provided by SOA
patterns can help architects gain insight of the service-oriented
mechanisms and can be used to explain how SOA represents a
particular type of architecture patterns.
B . SOA Patterns Selection based on Quality Requirements
When applying a specific architectur e pattern (including
SOA patterns), it may have a positive impact on certain quality
requirements while a negative impact on other quality
requirements (such as Performance and Security). Therefore,
when applying architecture patterns to design the architecture,
architects need to consider the balance and compromise of
multiple quality requirements . In [3], Buschmann et al .
introduce the commonly-used architecture patterns and how to
apply these patterns to achieve the system's quality
requirements. In [14], Muller et al. used questioning and
scoring to select appropriate patterns from a set of labeled
architecture patterns in order to meet the quality requirement s
and design scenarios in the architecture design. In [15], Stol et
al . introduce the methods and processes for identifying and
extracting architecture patterns from open source projects, in
order to evaluate and analyze implicit quality requirements of
the system, and to provide a basis for the evolution of the
architecture design. In this work, we provide a method to assist
architects in selecting appropriate SOA patterns based on the
quality requirements of the system. TABLE II shows the
selectable SOA patterns that an architect can employ to meet
one or several quality requirements of a system (e.g.,
Asynchronous Queuing for Reliability). Note that four quality
requirements (i.e., Reliability, Security, Reusability, and
Scalability) listed in TABLE I are considered in SOA patterns
selection in TABLE II, because not all quality requirements
can be well addressed by using certain SOA patterns .
TABLE II. SE LECTAB LE SOA PA TTERN S BASED ON S PECIFIC QUALITY
RE QUIREMENT S
Software Quality
Selectable SOA Patterns
Requirements
Reliability Agnostic Context, Asynchronous Queuing,
Composition Autonomy, Di stributed
Capability, Enterprise Service Bus,
Redundant Implementation, Reliable
Messaging, Service Encapsulation, Service
Facade, Service Grid
Security Brokered Authentication, Capability
Recompo sition, Data Confidentiality, Data
Origin Authentication, Direct
Authentic ation, Distributed Capability,
Exception Shieldin g, Invento ry Endp oint,
Messaging Metadata, Policy
Centralization, Service Encapsulation,
Service Perimeter Guard, Trusted
Subsystem
Reusability Agnostic Capability, Agnostic Context,
Agnostic Sub-Controller, Capability
363
Composition, Capability Recomposition,
Composition Autonomy, Concurrent
Contracts, Cross -Domain Utility Layer,
Data Pattern s Transform ation, Entity
Abstraction, Intermediate Routing, Logic
Centralization, Multi- Channel Endpo int,
Rules Centralization, Service Agent,
Service Layers, Utility Abstraction
Scalability Distributed Capability, Enterprise Service
Bus, Partia l State Deferral, Service Data
Replic ation, Service Grid, State
Repo sitory
When a service requires the client to mteract with this
service synchronously, synchronous messaging requires a real-
time feedback for each request, resulting in a bilateral data
exchange for each service interaction. When the service needs
to perform synchronous communication, both the service and
the service client are required to be available, and the data
exchange can be completed. In this situation an interaction
cannot be completed when either party cannot accept or send a
message, because the message is failed to send out or there is
no reply message, and consequently the Reliability of the
system execution are extremely low. With the application of
the Asynchronous Queuing pattern, the queuing mechanism is
introduced, and the queue acts as a temporary buffer to receive
the messages, and then the messages are transmitted to the
client. If the target service which receives the message is
unavailable , the queue acts as a temporary memory to save the
message, and then it can try to send the message again.
Similarly, when there is a reply message from the service, the
queue can also be used to temporarily store the reply message,
and then send the reply message to client service when it is
available. When the service or service client is processing the
content of the message, the other party can perform other
operations for the purpose of minimizing the memory
consumption. The use of the Asynchronous Queuing pattern
can prevent the situation of message transmission failure or no
reply message; thereby ensure the Reliability of the SOA-based
systems.
IV. CASE STU DY
We illustrate the applicati on of the method through the
architecture design of an online book distribution and sales
management system that has been implemented and availabl e
online. In the development of this system based on SOA, we
take the book retailing module as an example, and the
architecture design of this module is shown in Figure 1. When
multipl e retailers need to submit orders and payment
information to the vendor, the vendor needs an order service
and payment service which are capable of handling a large
number of transactions. For the retailers, they need to know
whether their orders have been completely submitted, and
whether the vendor s can process the orders correctly. For the
retailers , they also need to ensure that their payment
information is reliable and complete. In this SOA-based
system, a critical quality requirement that needs to consider is
Reliability .
As we can see from TABLE II, when considering the
quality requirem ent Reliability , there are ten SOA patterns that
 Retailer1
Retailer3
~ O'dij"'ce
P ayment •
REST Servk:e
Figure 1. The book retailing module based on SOA
can be used to meet this quality concern. The SOA patterns
that we can adopt when satisfying the architecture function of
this booking retailing module is Enterprise Service Bus (ESB)
and Reliable Messaging. The ESB pattern can handle services
described by different specifications to ensure that the services
are accurately distributed and processed. The Reliable
Messaging pattern can record the processing information of
high-throughput services and provide timely feedback to
service senders on the execution information of the services.
The architect can employ these two SOA patterns and add the
Persistent Repository database in the Reliable Messaging
pattern to the ESB pattern when designing the book retailing
module. The use of these two SOA patterns can ensure that the
vendors can use the order service to process different formats
of orders. Meanwhile it also ensures that the processing
information of the services is recorded and sent back to the
retailers in order to guarantee the Reliability of the system.
IV CONCLUSIONS
This paper introduces an SOA design method based on
software quality requirements and SOA patterns selection, and
extracted and refined twenty-one system quality requirements
that need to be considered in architecture design (including
SOA design) from existing literature. For the SOA-based
systems, the proposed method can assist architects in selecting
the appropriate SOA patterns according to the quality
requirements of the systems. We also show the application of
the method through an online book distribution and sales
management system as an example.
In the application of the general architecture patterns, there
is already some work on recommending patterns based on
quality requirements and their quantification [5], while in the
application of SOA patterns, the lack of SOA tactics is an issue
for the quantification. The next steps include (1) proposing a
quantifiable impact value assessment method to measure the
relationship between quality requirements and SOA patterns,
and better assisting architects to select and apply appropriate
SOA patterns based on quality requirements; (2) Software
systems often have multiple quality attributes, and SOA
364
Gathering
Service
patterns selection for addressing multiple quality attributes,
involving combination of SOA patterns, and quality attribute
conflicts between pattern applications. There is a need to
investigate the combination of SOA patterns while balancing
quality attribute conflicts.
REFERENCES
[1] Newcomer E, Lomow G. Understanding SOA with Web Services.
Addison-Wesley Professional, 2005.
[2] Josuttis N. SOA in Practice. O'reilly, 2007.
[3] Buschmann F, Meunier R, Rohnert H, Sommerlad P, Stal M. Pattern-
oriented Software Architecture: A System of Patterns. England: John
Wiley & Sons, 1996.
[4] Erl T. SOA Design Patterns. Prentice Hall, 2008.
[5] Chen X, Zhang W, Liang P, He K. A Replicated Experiment on
Architecture Pattern Recommendation based on Quality Requirements.
ICSESS 2014: 32-36.
[6] Ozkaya I, Bass L, Nord R L, Sangwan R S. Making practical use of
quality attribute information. IEEE Software, 2008, 25(2): 25-33.
[7] Berntsson S R, Gorschek T, Regnell B, Torkar R, Shahrokni A, Feldt R.
Quality requirements in industrial practice - an extended interview study
at eleven companies. IEEE Transactions on Software Engineering, 2012,
38(4): 923-935.
[8] International Organization for Standardization, ISO 25010: Systems and
software engineering - Systems and software Quality Requirements and
Evaluation (SQuaRE) - System and software quality patternss, 2013
[9] McCall J A, Matsumoto M T. Software quality measurement manual.
U.S.: Rome Air Development Center, Technical Report: lR-80-109,
1980.
[10] Bass L, Clements P, Kazman R. Software Architecture in Practice. 3rd
Edition. Boston: Addison Wesley, 2012.
[11] IEEE Standard Glossary of Software Engineering Terminology. IEEE
Std610.12-1990, 1, 1990.
[12] Buschmann F, Henney K, Schimdt D. Pattern-Oriented Software
Architecture: On Patterns and Pattern Language (Vol. 5). John Wiley &
Sons, 2007.
[13] Perry D E, Wolf A L. Foundations for the study of software architecture.
ACM SIGSOFT Software Engineering Notes, 1992, 17(4): 40-52.
[14] Muller M, Kersten B, Goedicke M. A question-based method for
deriving software architectures. ECSA 2011: 35-42.
[15] Stol K, Avgeriou P, Ali Babar M. Design and evaluation ofa process for
identifying architecture patterns in open source software. ECSA 2011:
147-163.