NEWS AT SEI
This article was originally published in News at SEI on: May 1, 2006
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.
Software Engineering Institute. Software Architecture Technology Initiative (2006).
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.