columns
the architect
Quality Attributes and Service-Oriented Architectures
Building systems to satisfy current and future mission/business goals is critical to the success of a business or organization. Software architecture is the bridge between mission/business goals and a software-intensive system. Quality-attribute requirements drive software architecture design [SEI 06]. Choosing and designing an architecture for such systems—one that satisfies the functional as well as the nonfunctional or quality-attribute requirements (reliability, security, maintainability, etc.)—are vital to the success of those systems. Recently, the use of service-oriented architecture (SOA) has gained widespread popularity as the approach for various types of systems. Although some work has been done on analyzing how particular quality attributes such as security and interoperability are handled within an SOA, we undertook a more thorough examination of the relationship between SOA and quality attributes.
The choice to use an SOA approach in the development of an architecture depends on several factors including the architecture’s ultimate ability to meet functional and quality-attribute requirements. Usually, an architecture must satisfy many quality-attribute requirements in order to achieve the organization’s business goals. In almost all cases, tradeoffs have to be made among these requirements. In some cases, satisfying these requirements may be easier using an SOA; in others, it may be more difficult. The following summarizes the results of our recent investigation into how an SOA supports quality attributes [O’Brien 05].
- Interoperability: Through the use of the underlying
standards, an SOA provides good interoperability support, allowing services
and applications built in different languages and deployed on different
platforms to interact. However, semantic interoperability is not fully
addressed. The standards to support semantic interoperability are immature
and are still being developed.
- Reliability: Undependable message transmission is
possible in many areas, but using Web Services (WS) Reliability and WS
Reliable Messaging standards can help. As with any element in an architecture,
service reliability is still an issue.
- Availability: It is up to the service users to negotiate
a service-level agreement (SLA) that can be used to set an agreed-upon
level of availability and to include penalties for noncompliance with
the agreement. Also, if a service user builds into its applications contingencies,
such as for handling exceptions when an invoked service is not available
(e.g., dynamically locating another source for the needed service), availability
should not decrease and could actually be improved in comparison to other
architectural approaches.
- Usability: If the services within the application
support human interactions with the system and there are performance problems
with the services, usability may decrease. It is up to the service users
and providers to build support for usability into their systems.
- Security: The need for encryption, authentication,
and trust within an SOA approach requires detailed attention within the
architecture. Many standards are being developed to support security,
but most are still immature. If these issues are not dealt with appropriately
within the SOA, security could be compromised.
- Performance: An SOA approach can have a negative effect
on the performance of an application due to network delays, the overhead
of looking up services in a directory, and the overhead caused by intermediaries
that handle communication. Both the service user and service provider
must design and evaluate their portions of an SOA-based design to ensure
that performance requirements are met.
- Scalability: There are ways to deal with an increase
in the number of service users and the increased need to support more
requests for services. However, these solutions require detailed analysis
by the service providers to make sure that other quality attributes are
not negatively affected.
- Extensibility: Extending an SOA by adding new services
or incorporating additional capabilities into existing services is supported
within an SOA. However, the interface or formal contract for services
must be extendable when necessary, without causing a major impact on the
service users’ applications.
- Adaptability: The use of an SOA approach should have
a positive effect on adaptability as long as the adaptations are managed
properly. However, the management of this quality attribute is left up
to the service users and providers, and no standards exists to support
it.
- Testability: Testability can be negatively affected
by the use of an SOA because of the complexity of the testing services
that are distributed across a network. Those services might be provided
by external organizations that do not have access to the source code and
therefore have no way of knowing the code coverage of a series of test
cases. Also, if the SOA uses runtime discovery of services, it may be
impossible to identify which services are used until a system executes.
It is up to the service users and providers to test the services, and
very little support is currently provided for the end-to-end testing of
an SOA.
- Auditability: Auditability can be negatively affected
if the right capabilities for end-to-end auditing are not built into the
system by the service users and are not incorporated into the services
by the service providers.
- Operability and deployability: Operation and deployment
of services and systems that use other services must be managed carefully
to help meet the quality of service (QoS) specified in SLAs. The interactions
and tradeoffs among this and other quality attributes must be monitored
and managed.
- Modifiability: Because the underlying logic is hidden behind the service interface, modifiability of services or an application that uses them is directly supported using an SOA approach. However, that interface must be designed to mitigate changes, since the effect of changes on external users of the service might be difficult to identify if the service is externally available.
Choosing and designing the right architecture for a system—one that satisfies its functional and nonfunctional (quality-attribute) requirements—are vital to the success of that system. It is particularly important to examine how using an SOA supports the quality attributes most critical to that system. When an organization designs and implements a system using an SOA approach, it must make various tradeoffs among the quality-attribute requirements that will affect whether the organization will fully meet its business goals. SOA is still an emerging technology, many of the issues between SOA and quality attributes have not been thoroughly researched, and many of the standards posing as remedies are immature.
If external services, or even those outside the control of the development department, are used, an SLA must be established between the various parties to guarantee QoS for a set of essential services. Building a system that relies on third parties without the necessary agreements in place can make it difficult for the system to meet its quality-attribute requirements. Failing to meet them would adversely affect an organization’s ability to meet its business goals and, in turn, its success.
We are continuing to investigate the relationship between quality attributes and SOAs, so be sure to look for more information on this topic in our future columns.
References
[SEI 06]
Software Engineering Institute. Software
Architecture Technology Initiative (2006).
[O’Brien 05]
O’Brien, L.; Merson, P.; & Bass, L. Quality
Attributes and Service-Oriented Architectures (CMU/SEI-2005-TN-014).
Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University,
2005.
About the Authors
Liam O’Brien works for the Irish Software Engineering Research Centre, Limerick, Ireland. Until recently, he was a senior member of technical staff at the Software Engineering Institute, where he worked in the areas of service-oriented architectures, modernization of legacy systems, architecture reconstruction, and architecture-centric software life cycles. His latest publications include several reports published by Carnegie Mellon and papers at various international conferences on these subjects. He has more than 16 years of experience in software engineering practice and research.
Len Bass is a senior member of the technical staff at the Software Engineering Institute who participates in the High Dependability Computing Program. He has written two award-winning books on software architecture as well as several other books and numerous papers in a wide variety of areas of computer science and software engineering. He is currently working on techniques for the methodical design of software architectures and to understand how to support usability through software architecture. He has been involved in the development of numerous production or research software systems ranging from operating systems to database management systems to automotive systems.
Paulo Merson is a member of technical staff at the Software Engineering Institute, where he works in the Software Architecture Technology and the Predictable Assembly from Certifiable Components Initiatives. He is currently investigating service-oriented architectures, aspect-oriented software development, model-driven development, and software architecture representation. Merson has more than 15 years of experience in software development. Prior to joining the SEI, he was a J2EE consultant and worked on the implementation of several enterprise applications.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.