Abstract:
This report examines the relationship between service-oriented architectures (SOAs) and quality attributes. Because software architecture is the bridge between mission/business goals and a software-intensive system, and quality attribute requirements drive software architecture design, it is important to understand how SOAs support these requirements. This report gives a short introduction to SOAs and outlines some of the main business goals that may lead an organization to choose an SOA to design and implement a system. This report outlines a set of quality attributes that may be derived from an organization’s business goals and examines how those attributes relate to an SOA. In addition, this report describes how the SOA impacts those attributes and how choosing an SOA can help an organization achieve its business goals.
Introduction:
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 05]. 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 a service-oriented architecture (SOA) as the underlying architecture has been gaining popularity and widespread use as the architectural approach for various types of systems. Though some work has been done on how particular quality attributes such as security and interoperability are handled within an SOA, a more thorough examination of the relationship between SOA and quality attributes is needed. Such an examination is the subject of this report.
There are various definitions of what constitutes an SOA, some of which are outlined in Section 2 along with principles of service orientation. In this report, we use the term service-oriented architecture to mean an architectural approach for building systems or applications that use a set of services and not just a system that is built as a set of services. A service is an implementation of a well-defined piece of business functionality, with a published interface that is discoverable and can be used by service consumers when building different applications and business processes.
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 needs to satisfy many quality attribute requirements in order to achieve the organization’s business goals. In almost all cases, tradeoffs have to be made between these requirements. In some cases, satisfying these requirements may be easier using an SOA; on others, it may be more difficult. If an SOA is being considered, several questions need to be asked; for example:
What effect will the choice of an SOA have on the business goals?
Which quality attribute requirements will be positively impacted and which will be negatively impacted by the use of the SOA?
What tradeoffs need to be made among the quality attributes?
Within the Department of Defense (DoD), digital information is rapidly becoming integrated into all aspects of military activities [Cherinka 05]. The DoD’s goal is to find new and better ways of managing information and providing capabilities in response to quickly changing needs. The DoD is currently using the Network Centric Warfare (NCW) approach [Alberts 99]. This approach entails the networking of information producers (e.g., sensors); decision makers and consumers to achieve shared awareness; increased speed and quality of decision making; and a higher tempo of dynamic operations. One of the approaches being employed to support NCW is SOA. This report does not address the DoD’s usage of SOA but rather fundamental technical information about SOA. This report explores the relationships among business/mission goals, quality attribute requirements, and the use of an SOA approach.
This report is structured as follows. Section 2 has an introduction to SOAs and service-orientation principles. Section 3 outlines some business goals that an organization may have that would lead to choosing an SOA approach. Section 4 examines some quality attributes that may be important in helping an SOA achieve an organization’s business goals. Section 5 outlines which of the quality attributes are supported and which are violated by the use of an SOA and then summarizes the impact of the SOA on the achievement of the organization’s business goals. Section 6 summarizes the work outlined in this report.
Conclusion:
Software architecture is the bridge between mission/business goals and a software-intensive system. Quality attribute requirements drive software architecture design. Choosing and designing an architecture for such systems that satisfies the functional as well as the nonfunctional or quality attribute requirements are vital to the success of those systems. An SOA is an architecture for a system that is built using a set of services. It is import to examine how an SOA supports quality attributes. This report examines several quality attributes, explores how an SOA supports them, and identifies issues and problems related to them. The SEI is investigating how this information impacts the DoD and its use of SOAs—a topic that will be the subject of future reports.