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:

• services that represent a reusable business functionality exposed via standard service interfaces
• service consumers that use the functionality provided by these services as part of the processes they implement
• an SOA infrastructure that connects service consumers to services

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

• easy and flexible integration with legacy systems (interoperability)
• streamlined business processes (maintainability)
• reduced costs (modifiability)
• agility to handle rapidly changing business processes (extensibility)

Common components of an SOA infrastructure that can help meet some of these quality attributes include

• a service registry and repository, which can be custom-built or, more commonly, provided by a product in the SOA infrastructure. Typical functionality includes dependency management, discovery, versioning, event notification, access control, policy management, and federation capabilities.
• a messaging system, also known as message-oriented middleware, which is often a part of execution environment of enterprise applications. A messaging system allows distributed components to exchange asynchronous messages. Today messaging systems are commonly used in service-oriented systems for transactions that involve background processing because they provide high levels of scalability and reliability.
• a business process engine, which is a software component responsible for processing incoming requests by performing the steps--defined according to rules--of business processes that correspond to that request. A key element of the business process engine is a business process modeling (BPM) tool that enables the description--and often visualization--of the business processes. The BPM tool then generates a business process that is deployed to and executed by the business process engine when processing requests.
• monitoring and management tools, which enable organizations to detect, diagnose, and react to potential problems in service-oriented systems. These tools are used for runtime monitoring to provide information that can be used to maintain system quality of service and to inform tactics and patterns, such as dynamic load balancing, failover and recovery procedures, and service removal and replacement.

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

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

• ensuring that service providers and service consumers can make independent decisions about technology
• creating services that are independent, self-contained capabilities that can be used in isolation from those capabilities provided by other services
• enabling the actual binding between a service consumer and a service at runtime

Reusability

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

• identify services that perform utility operations, such as logging and data manipulation, and design them so they are independent of the business processes that use them
• design (when possible) stateless services that do not maintain a conversational state
• provide an infrastructure that abstracts or mediates differences between service consumers and service interfaces, such as different versions of standards (e.g., SOAP 1.1 vs. SOAP 1.2) or data formats (e.g., XML vs. CSV).

Composability

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

• self-contained functionality
• standardized interfaces
• availability in a service registry

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

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

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.

Additional Resources

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
http://www.sei.cmu.edu/saturn/2013/courses/index.cfm#advsoa

To read the SEI technical report, Architecting Service-Oriented Systems, please visit
http://www.sei.cmu.edu/library/abstracts/reports/11tn008.cfm

To view the first installment of a virtual tutorial that Grace presented on Architecture and Design of Service-Oriented Systems, please visit
http://www.sei.cmu.edu/library/abstracts/webinars/Architecture-and-Design-of-Service-Oriented-System.cfm