Evaluating a Service-Oriented Architecture

Posted by Hartmut Wilms on Oct 18, 2007

Sections

Process & Practices,

Architecture & Design,

Enterprise Architecture

Topics

SOA ,

Methodologies

The Software Engineering Institute has published a new paper "Evaluating a Service-Oriented Architecture".

The report should serve as a basis for an architecture evaluation in the early stages of the SOA life cycle. The architectural approaches and design considerations of an SOA have to be evaluated according to the quality requirements of an organization in order to effectively identify and weigh their risks and benefits:

The emergence of service-oriented architecture (SOA) as an approach for integrating applications that expose services presents many new challenges to organizations resulting in significant risks to their business. Particularly important among those risks are failures to effectively address quality attribute requirements such as performance, availability, security, and modifiability. Because the risk and impact of SOA is distributed and pervasive across applications, it is critical to perform an architecture evaluation early in the software life cycle. This report contains technical information about SOA design considerations and tradeoffs that can help the architecture evaluator to identify and mitigate risks in a timely and effective manner. The report provides an overview of SOA, outlines key architecture approaches and their effect on quality attributes, establishes an organized collection of design-related questions that an architecture evaluator may use to analyze the ability of the architecture to meet quality requirements, and provides a brief sample evaluation.

The paper starts with an introduction to Service-Oriented Architecture. Service-oriented principles and characteristics are described, and SOA and Web Services are defined as an architectural style and one of several possible implementations. The introduction ends with a discussion of drivers for Service-oriented architectures.

The main part of the report covers the architectural approaches and the design considerations of an SOA. Architectural approaches are divided into communication, integration, composition, and binding of services. According to the authors service interaction can be implemented in three different approaches. The distinction complies with the three SOA Styles described by Stefan Tilkov on his blog: RPC-style Web services, Message-oriented Web services, and REST. Integration and service composition can be implemented directly by point-to-point connections and composite services. Alternatively they might be realized by making use of a brokering software, such as an Enterprise Service Bus (ESB), and a BPEL orchestration engine. The discussion about architectural approaches also encompasses the question whether services should be bound dynamically via a service registry or statically by defining service-endpoints within proxy code or configuration files.

Architectural design decisions have to be determined considering quality attribute or non-functional requirements. Typical SOA design decisions include the following topics:

• target platform
• synchronous versus asynchronous services
• granularity of services
• exception handling and fault recovery
• security
• XML optimization
• use of a registry or services
• legacy systems integration
• BPEL and service orchestration
• service versioning

Each of these topics is briefly described and discussed in regard to quality attributes. Sample evaluation questions help to decide which of the possible design alternatives most efficiently achieves the system requirements.

The report closes with an SOA architecture evaluation example. The example follows the Architecture Tradeoff Analysis Method (ATAM) developed by the SEI:

The SEI's Architecture Tradeoff Analysis Method^® (ATAM^®) is the leading method in the area of software architecture evaluation. An evaluation using the ATAM typically takes three to four days and gathers together a trained evaluation team, architects, and representatives of the architecture's various stakeholders. Proven benefits of the ATAM include

• clarified quality attribute requirements
• improved architecture documentation
• documented basis for architectural decisions
• identified risks early in the life-cycle
• increased communication among stakeholders

The report gives a good overview of architectural approaches and design decisions within the context of service orientation and presents ATAM as a means of evaluating an SOA.

• Older >