Posted on by
In 2009, a popular blogger published a post entitled "SOA is Dead," which generated extensive commentary among those who work in the field of service-oriented architecture (SOA). Many practitioners in this field completely misinterpreted the post; some read the title and just assumed that the content referenced the demise of SOA. Quite the opposite, the post was inviting people to stop thinking about SOA as a set of technologies and start embracing SOA as an approach for designing, developing, and managing distributed systems that goes beyond just the technology.
Unfortunately, even though SOA is still alive and widely adopted, a belief still persists that SOA can be purchased off the shelf. This post highlights recent research aimed at clarifying this misperception for architects, as well as identifying the elements that constitute a service-oriented system and the relationships between these elements.
Service Orientation in a Nutshell
Service orientation is a way of designing, developing, and deploying software systems. The architecture of a service-oriented system can typically be characterized by three high-level components:
Rather than being viewed as an off-the-shelf product, SOA should be viewed as an architectural style or paradigm for designing systems. From this paradigm, an infinite number of configurations can be derived that either benefit or harm a system.
Even organizations that acquire products to build a service-oriented system from a vendor must contend with numerous architectural and design decisions. These decisions include deciding what services to expose and whether the functionality exposed comes from legacy systems, is built from scratch, or is acquired from a third party. Other critical considerations include deciding how information about the system will be accessed and shared, as well as how to promote quality attributes that are important for a particular organization. For example, service-oriented systems typically promote interoperability and modifiability at the expense of optimal performance and stringent security.
Implementing a Service-Oriented System
Many architectural and design decisions must be made when implementing a service-oriented system. When an organization acquires an SOA infrastructure product, such as an enterprise service bus (ESB), from a vendor it is buying only one piece of the service-oriented system.
The architecting of a service-oriented system, however, begins when the system stakeholders define the quality attributes that must be met by the system, such as
Common components of an SOA infrastructure that can help meet some of these quality attributes include
SOA Architecture Principles
Service-oriented systems, like any system, have business mission goals and a corresponding set of desired quality attributes that drive the architecture of the system. SOA, as an architectural style, has a set of service-oriented principles that influence the architecture of a system and impact a system's quality attributes. When these two sets of quality attributes collide, conflicts arise, and architects must apply each principle in the context of the business goals of the system to make necessary tradeoffs and to make architecture decisions to meet the system's business goals. Some of the key principles are described below
Loose coupling can play a great role in impacting quality attributes (either positively or negatively) in SOA adoption. Architects can enable loose coupling by making several key decisions, including
Reusability mostly refers to service reusability, which includes services that are reusable because they represent self-contained functionality that can be reapplied in multiple business processes. If service reusability is a goal, architects should
Composability enables organizations to rapidly change elements of a business process in response to changes in the business environment, without impacting consumers of the composite service that implements the business process. Service composability relies on many of the same characteristics as service reusability including
Composability introduces architectural risks that require strategies for mitigation, including compositions with services that span multiple organizational boundaries or transactions that contain services that belong to different systems.
Discoverability in a service-oriented environment refers to the creation and publication of services in a location (such as a service registry, web page, or directory) that is accessible to and can be queried by service consumers. Metadata associated with a service includes its interface specification or contract in addition to any other data that can help a developer make decisions about whether or not to use that service.
Standardization is perhaps the service-oriented principle that has contributed the most to widespread SOA adoption. Especially for Web Services, standardization has driven the creation of a large amount of tools and third-party components that can be leveraged by developers and can effectively lead to shorter development and deployment times. In addition, standardization enables the leverage of legacy systems because these can remain in their native platforms while exposing their functionality via standard interfaces.
A caveat when using Web Services is that while the basic WS-* stack (HTTP, XML, WSDL, SOAP) has remained fairly stable over the years, other standards such as, WS-Security, WS-Transaction, or WS-Addressing continue evolving and contain areas that are subject to multiple interpretations. Aware of this shortcoming, the WS-I organization was created to promote interoperability by providing clarifications, refinements, interpretations, and amplifications in areas of specific standards that are indeed subject to multiple interpretations.
Applying Our Research on Service-Oriented Systems
I authored, with fellow researchers, a technical report that described the effect that service-oriented principles have on system quality attributes. As an architectural style, SOA may be an appropriate solution in some situations, but there will be other situations where it is not appropriate, or it has to be used in conjunction with other technologies to achieve the desired system qualities. SOA architects are often at a conflict because on one hand there are business and mission goals that dictate the quality attributes that are important for the system. On the other hand, SOA architects using service-orientation want to adhere to service-orientation principles and leverage those to the advantage of the system.
Our intent in documenting our research is to help architects of service-oriented systems design better systems and understand the tradeoffs. Later this month, at the SEI Architecture Technology User Network (SATURN) Conference (SATURN 2013), my SEI colleague, Stephany Bellomo, will be teaching a two-day course, Advanced Topics in Service-Oriented Architecture, that expands on the concepts presented in this posting.
To learn more about the course, Advanced Topics in Service-Oriented Architecture, which was offered April 29 and 30, 2013, at SATURN 2013, please visit
To read the SEI technical report, Architecting Service-Oriented Systems, please visit
To view the first installment of a virtual tutorial that Grace presented on Architecture and Design of Service-Oriented Systems, please visit