NEWS AT SEI
This article was originally published in News at SEI on: July 1, 2007
Most of the practitioner-oriented materials about service-oriented architectures (SOAs) build on the SOA hype and focus on the benefits of SOA in terms of achieving business goals. Those benefits are real and substantial, but what about the many design decisions architects must make that affect the system’s performance, interoperability, security, and modifiability? What can architects do to mitigate the risk of failing to meet those quality attribute requirements? According to the Software Engineering Institute (SEI), the answer is an early architecture evaluation.
In their technical report titled Evaluating a Service-Oriented Architecture, SEI researchers Paulo Merson and Phil Bianco, along with Rick Kotermanski of Summa Technologies, describe SOAs and discuss SOA design considerations and tradeoffs that can help the architecture evaluator identify and mitigate risks in a timely and effective manner.
There are many definitions of SOA, but none is universally accepted. However, according to researchers at the SEI, one central notion is common to them all—that of service. An ideal SOA service
- is self-contained
- is a distributed component
- has a published interface
- stresses interoperability
- is discoverable
- is dynamically bound
From the point of view of a software architect, SOA is as an architectural style where systems consist of service users and service providers. Because SOA involves multiple systems, business entities, and technologies, its overall complexity and the political forces involved need to be factored into architecture tradeoff considerations more than in single-application designs where technical concerns predominate. One method that can be used to conduct SOA evaluations without any adaptation is the SEI Architecture Tradeoff Analysis Method(ATAM)—a method for evaluating software architectures relative to a system’s quality attribute requirements. In addition to revealing how well an architecture satisfies particular quality goals, the method provides insight into how they interact with each other—that is, how they trade off against each other.
To guide evaluators and help them identify and mitigate risks to their systems, researchers at the SEI have compiled information about the architectural approaches and design considerations and tradeoffs that are particularly relevant to SOA. Because architectural design decisions determine a system’s ability to meet functional and quality attribute goals, asking the following questions when designing an SOA can be especially helpful:
These design decisions affect quality attributes such as interoperability, performance, modifiability, usability, and, evidently, security.
- Is XML optimization being used? XML is the most common format for data representation in SOA solutions. It is flexible, extensible, widely adopted, and the underpinning for interoperability in most SOA technologies. However, parsing, validating, and transforming XML data are memory- and CPU-intensive operations that can deeply impact the scalability and performance of the system.
- Is a service registry being used? In larger and rapidly changing SOA environments, it is difficult to manage the availability, capabilities, policies for use, and location of shared services. This difficulty results in the risk of quality failures. An SOA service registry provides the registration of services, management of metadata, and automation for the creation of and access to services.
- How are legacy systems integrated? There is typically more than one reasonable way to integrate a legacy system into an SOA environment. The architect must weigh the associated cost/benefit tradeoffs when selecting the integration strategy.
- Is Business Process Execution Language (BPEL) used for service orchestration? BPEL is an XML-based language for describing business process workflows that involve the interaction with multiple services. A BPEL engine executes code written in BPEL and coordinates the invocation of the services in the workflow. There are modifiability, interoperability, performance, and reliability implications both for using BPEL and for not using it. The architect must consider those implications when deciding whether to use the language.
- What approach is used for service versioning? Services and even individual operations within a service can be versioned independently of other system components. When the service is used by an unknown number of external service users, a common requirement is for old and new versions to coexist. That requirement makes configuration management and deployment more complex.
Because decisions about SOA tend to be pervasive and have a significant and broad impact on business, performing an early architecture evaluation is particularly valuable and highly recommended. Balancing SOA aspects against other software architecture concerns is particularly challenging in an SOA software architecture evaluation.