Concept: Service Oriented Architecture
Service-Oriented Architecture (SOA) is characterized along several dimensions: as a generalized approach for thinking about systems, as a technology infrastructure, as a framework for IT design, as a bridge between business and IT, and as an evolution of component-based and OO techniques.
Relationships
Related Elements
Main Description

Introduction

Service Oriented Architecture (SOA) is a way of organizing and understanding organizations, communities, and systems to maximize agility, scale, and interoperability. The SOA approach is simple - people, organizations, and systems provide services to each other. These services enable us to get something done without doing it ourselves or even without knowing how to do it, enabling us to be more efficient and agile. Services also enable us to offer our capabilities to others in exchange for some value, thus establishing a community, process, or marketplace. The SOA paradigm works equally well for integrating existing capabilities, as well as creating and integrating new capabilities.

A service is an offer of value to another through a well-defined interface.  It is available to a community (which might be the general public). A service results in work provided to one by another. SOA, then, is an architectural paradigm for defining how people, organizations, and systems provide and use services to achieve results.

SOA has been associated with a variety of approaches and technologies. The view expressed here is that SOA is foremost an approach to systems architecture, where architecture is a way to understand and specify how things can best work together to meet a set of goals and objectives. Systems, in this context, include organizations, communities, and processes as well as information technology systems. The architectures described with SOA can be business architectures, mission architectures, community architectures, or information technology systems architectures - all can be equally service oriented. The SOA approach to architecture helps with separating the concerns of what needs to get done from how it gets done, where it gets done, or who or what does it.

SOA in the IT Realm

The difficulties in building enterprise-scale software solutions arise from at least four primary sources of challenges:

  1. Understanding highly complex business domains.
  2. Assessing the most efficient use of IT resources to meet the needs of the business.
  3. Managing a development effort involving large teams of engineers over multiple phases of a project spanning many months.
  4. Deploying solutions to a complicated assortment of infrastructure technologies that have evolved over multiple years, consist of a variety of middleware software acquired from many vendors, and were assembled through poorly documented integration efforts of varied quality.

To develop solutions in this context requires an approach to software architecture that helps architects evolve their solutions in flexible ways and reuse existing efforts in the context of new capabilities that quickly implement business functionality even as the target infrastructure itself is evolving. The SOA paradigm can be used effectively to create the loosely-coupled IT systems that offer the flexibility and potential for reuse that are desirable.

However, moving toward SOA provides many challenges to an organization. Service-oriented concepts, for example, introduce new terms and models and promote interoperability and process integration. Additionally, integrating the many underlying technology layers that constitute a SOA can be a complex task. IT organizations often find that they require changes in approach, upgrades to their skill set, new capabilities in their development environments, and changes to solutions-design processes. To compound this, the concept of SOA is a recent phenomena and its characteristics are continuing to evolve. However, there are several clear perspectives on what is an SOA and the role of a SOA in addressing key concerns in building enterprise software solutions.

SOA as a Technology Infrastructure

Systems are composed of collections of services making calls on operations defined through their service interfaces. Many organizations now express their solutions in terms of services and their interconnections. The ultimate goal of adapting a SOA is to achieve flexibility for the business and within IT. A number of important technologies have been defined to support an SOA approach, most notably when the services are distributed across multiple machines and connected over the Internet or an intranet. These web-service approaches rely on intra-service communication protocols such as SOAP; enable web service interfaces (expressed in the Web Services Definition Language - WSDL) to be registered in public directories and searched in Universal Description, Discovery and Integration (UDDI) repositories; and share information in documents defined in the XML and described in standard schemas. Additionally, standards are being developed to address additional areas of policy, security, reliability, discovery, and more; this family of standards is commonly known as the "WS-* family".

But SOA is no more simply a set of standards and service descriptions than object-orientation is simply a set of class hierarchies. Indeed, it is possible to create a SOA that does not use Web services technology, and it is possible to use web services technology in a way that would not be considered service-oriented. There is a great deal more that needs to be explored to understand why a service-oriented viewpoint adds value to the business, and how service-oriented solutions are designed, implemented, deployed, and managed.

SOA as a Conceptual Framework for Design

Creating solutions for SOA means rethinking the kinds of systems being built today, reconsidering the skills in an organization, and redefining the ways in which members of teams collaborate. Most importantly, adopting a services orientation to development of solutions requires a broader review of its impact on how solutions are designed, what it means to assemble them from disparate services, and how deployed services-oriented solutions are managed and evolved.

One key change in this move is that the term "application" as we have known it is becoming problematic as we move from the application as being the center of all projects to the focus being on the portfolio of services a business relies on. In this regard, we can think of this move from application-oriented projects to service-oriented projects as a move from the design of a vertically integrated set of components that make an application toward the design of a horizontal set of services. In the future, we see the term application being relegated to the description of a small layer of specific business logic close to the user interaction services that choreographs the set of business and infrastructure services that provide the bulk of the value.

Gartner refers to this broader context of service-orientation as Service-Oriented Development of Applications (SODA). Gartner considers the five key tenets of SODA to be composition, adaptive process management, services-based interoperability and integration, discovery and description, and rapid application maintenance. From a tool vendor perspective, these areas relate to technology support offered in three areas:

SOA Life Cycle. The "Discovery and Description" and "Rapid Application Maintenance" tenets refer to the life cycle of services and how they are found, applied, evolved, and maintained. Tool vendors are increasingly offering ways to store, catalog, search, and retrieve services. Support for the ongoing evolution of services is a critical aspect of this, leading to multiple versions of services.

SOA Platform and Programming Model. The Service-Based Interoperability and Integration tenet refers to the way services can be connected, deployed, and managed within a specific runtime platform. The major platform vendors are supporting services-oriented capabilities directly as part of the middleware runtimes, and evolving their runtime programming models to surface service concepts as first class elements. As a result, solutions can be conceived, designed, implemented, and managed from a single service-based perspective.

SOA Practices and Tools. The Composition and Adaptive Process management tenets refer to how services are created and assembled in the context of solving changing business needs. Tool vendors support mining existing applications to discover potential services, wrapping existing functionality to make those capabilities accessible as services, creation of new services, and connecting services by connecting behavior exposed through their interfaces. Fundamental to this is the availability of clear guidance and best practices for architecting services-oriented solutions in repeatable, predictable ways.

All three of these areas are important to success in developing services-oriented solutions. They must all be addressed to meet an organization's needs for efficiently creating more flexible solutions that better align with the goals of the business.

SOA as an Holistic Approach to Solutions that Bridge Business and IT

One of the primary challenges to be addressed in developing enterprise-scale solutions is to connect the domain-specific requirements expressed by business analysts with the technology-specific solutions designed by the IT organization. Typically, the connection between these two disparate worlds is not good. The two communities have very different skills, use different modeling concepts and notations (if at all), and rarely understand the mapping between those concepts. The use of a service-oriented approach is intended to help bridge this gap between the business analysts and line-of-business specialists and IT specialists such as architects, system analysts, integrators, designers and developers. In particular, the integration of process, assets, and deliverables around a core set of services is intended to connect these two different aspects of the system in a clear, precise way.

SOA offers a service-focused view to help overcome these challenges:

Bridging the Business-to-IT gap. It is essential to align the business view of activities and processes with the technology that is used to realize parts of these activities. This alignment includes the ability for business models to drive downstream development and to evolve the business models and IT solutions in combination. The service concept is critical to this alignment. Services and service-based thinking form the common ground that ties together business analysts, IT architects, integrators, and developers. The very nature of services, the level of granularity and level of encapsulation that they promote, enables them to be much closer aligned to the business process models that drive the business. Common design practices are essential to this to ensure that the concepts, work products, and tasks are synchronized across these different perspectives. Finally, having tools which can efficiently transform models representing the business intent into efficient implementations are very important for bridging the Business-to-IT gap.

Supporting the changing roles in the IT organization. The move to services thinking changes the skills and composition of teams in an organization. The focus of development is on finding, defining, managing, and assembling services, with architectural descriptions highlighting service level agreements (SLAs) and inter-service protocols. The traditional breakdown of tool functions into today's line-up of products is not appropriate to this approach. There will be a different blend of capabilities required by the different members in IT organizations. For example, the skills required by existing roles such as software architect are changing to include greater emphasis on assembly and management of services across a diverse set of service providers. Similarly, new roles such as integration specialists are emerging, with a focus on assembling a services-based value chain in support of an organization's key business goals.

Focusing on assets and reuse. Considering services as key assets in the design of systems changes an organization's view of the value of reusing these services. Earlier, we discussed the move from vertical development of a set of application components to the horizontal integration of components. One valuable aspect of this is that the services themselves become much more available for reuse. In fact, their combination into new capabilities, their composition into new services, is a fundamental driver for change. In many businesses, this promise of greater reuse from a SOA justifies the cost associated with the design and development of a portfolio of services. As a result, technologies and techniques for managing and governing assets and repeatable ways to capture patterns for combining assets become much more important. In an asset-based development approach, these assets hold critical value to the organization and must be carefully managed and administered. The team infrastructure for managing assets takes on a key role in this approach.

Increasing the levels of collaboration within and across practitioner roles. Successful Enterprise-scale application development has always depended upon the ability of people to people work together and focus their attention across the life-cycle on managing shared assets, establishing work product traceability, and sharing practices and processes. As organizations become more geographically distributed and software becomes embedded as one part of broader systems development initiatives, the importance of effective collaboration among and between teams increases. To support these evolving organizations and missions, software development infrastructures must become effective collaborative development environments that encourage sharing and reusing services across teams.

SOA as an evolution of Component-Based and Object Oriented Techniques

In any new development in software engineering, it is very easy to assume that one can apply the same techniques and tools that have worked in previous projects. This tendency to solve new problems with outdated solutions is not new. In a similar way, as developers began to create component-based applications, they tried to address problems by using their experience with object-oriented development. With more experience, it was understood that object-oriented technology and languages are great ways to implement components, though one has to understand the trade-offs made through decisions and implementation. Trade-offs include choices such as using inheritance versus aggregation for implementing polymorphic behavior, and redesigning class libraries to be able to use sets of components, rather than objects, as the base for a monolithic C++ application.

In a similar way, we see components as the best way to implement services, though one has to understand that an exemplary component-based application does not necessarily make an exemplary SOA. We see a great opportunity to leverage your company's component developers and existing components, once the role played by services in application architecture is understood. The key to making this transition is to realize that a service-oriented approach implies an additional application architecture layer. The picture below demonstrates how technology layers can be applied to application architecture to provide more coarse-grained implementations as one gets closer to the consumers of the solution. The term coined to refer to this part of the system is "the application edge", reflecting the fact that a service is a great way to expose an external view of a system, with internal reuse and composition using traditional component design. One way to look at the differences between objects, components and services is the way they are coupled to their implementation; objects are tightly coupled to their programming language, and components are coupled to some runtime or platform (COM, CORBA, J2EE, and such), whereas services are really only coupled to the set of standards used to describe their specification.

In general, the move from object-oriented to component-based thinking took between 6 and 18 months, as developers learned about this new technology and its requirements. Hopefully, the move to service-oriented solutions can happen more quickly. Developers will have to understand the challenges, trade-offs, and design decisions that come into play during the development and reuse of components to support service-oriented solutions