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:
-
Understanding highly complex business domains.
-
Assessing the most efficient use of IT resources to meet the needs of the business.
-
Managing a development effort involving large teams of engineers over multiple phases of a project spanning many
months.
-
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
|