features
Mitigating the Risk of Using Service-Oriented Architectures
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®
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:
- What communication mechanisms are used? Service users and service providers can communicate via
- Simple Object Access Protocol (SOAP) Web services
- messaging systems such as Microsoft MSMQ and IBM WebSphere MQ
- a simplistic but innovative approach called Representational State Transfer (REST)
- a mix of these alternatives and proprietary communication protocols, varying from Systems Network Architecture/Logical Unit (SNA/LU) 6.2 to Internet Inter-ORB Protocol (IIOP)
The right choices will help to achieve the desired interoperability, modifiability and performance.
- Is an ESB part of the solution? The Enterprise Service Bus (ESB) is a component that intermediates the communication between service users and service providers. The ESB can route, split, and merge messages; transform data’s content and format; verify authorization; and adapt messages to different platforms/technologies. The gains in terms of modifiability, interoperability, and extensibility have to be weighed against the performance overhead and the initial cost and complexity of implementation. For smaller systems with a more homogeneous platform and a slower pace of changes in business and technology, direct point-to-point integration among service users and providers may work better than using an ESB.
- What is known about the target platform? In SOA solutions, many quality concerns are primarily handled or strongly affected by the runtime infrastructure. For this reason, architects should be familiar with the target platforms, including the runtime environment for service users and service providers, the network infrastructure, and the platforms used by external services.
- Should a service be synchronous or asynchronous? In an SOA, services may be provided through either synchronous or asynchronous interfaces. Each option has pros and cons to consider, and the selection of a service interaction approach depends on a combination of business and application logic requirements, existing component capabilities, and other architectural factors.
- Should a service have a coarse- or fine-grained interface? A coarse-grained service interface typically consists of operations that require less communication and are designed to do more work with fewer service calls than fine-grained services. Service interface granularity has architectural and business implications and is a critical factor for achieving performance, reusability, and modifiability requirements when implementing an SOA. Designing a service that is “right” grained depends primarily on how the service will be used, but the architect should also consider which quality attributes are most important to system stakeholders.
- What strategies are being used for exception handling and fault recovery? Achieving reliability, availability, and serviceability requirements is difficult in SOA systems, because they sometimes involve heterogeneous platforms and protocols, as well as external services. A robust SOA-based architecture must deal with application and system failures at a variety of levels, such as the system infrastructure, networking, and data services. Establishing proper debugging, logging, and tracing components and related standards helps to detect failures and identify potential sources. Error-handling strategies can also manage the behavior of the system under failure modes.
- Does the SOA involve https or message-level security? Https is a simple and popular alternative to protect the communication pipes at the transport level in SOA solutions. However, it doesn’t protect the message when it is processed by intermediary components. Message-level security provides an end-to-end solution that protects the message itself, but there are interoperability concerns.
- How is service authentication and authorization managed? Authentication and authorization in SOA solutions involve several design decisions regarding
- access-control mechanisms (e.g., digital certificates, declarative or programmatic authorization)
- technology (e.g., Lightweight Directory Access Protocol [LDAP]) and scope (e.g., enterprise wide, local) for security domains
- access-control data representation format (e.g., Security Assertion Markup Language [SAML])
- conformance to regulations (e.g., Health Insurance Portability and Accountability Act [HIPAA], Sarbanes-Oxley)
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.
For more information, go to http://www.sei.cmu.edu/publications/documents/07.reports/07tr015.html or contact Paulo Merson at pfm@sei.cmu.edu.