SOA Basics
This chapter is from the book
This chapter is from the book
This chapter is from the book
- Delusions, errors, and lies are like huge, gaudy vessels, the rafters of which are rotten and worm-eaten, and those who embark in them are fated to be shipwrecked.
- —Buddha
Service-oriented architecture (SOA) is defined in a number of ways, but not all definitions are equal, and not all definitions are complete. Instead of just providing another definition of SOA, this chapter describes the basic building blocks of SOA and looks at the value proposition of SOA from key stakeholder perspectives. Besides covering the basic building blocks of SOA, its DNA, and the value propositions of adopting SOA and its ultimate utility, this chapter describes what makes an implementation an SOA deployment. Specifically, this chapter addresses the following questions:
- What is SOA?
- Is SOA an architectural style?
- What are fundamental constructs (the DNA) of SOA?
- What is the difference between a Web Service and an SOA service?
- What makes a project an SOA implementation?
SOA Basics: Q&A
1. What Is SOA?
Numerous vendors, application providers, system integrators, architects, authors, analysts firms, and standards bodies provide definitions of SOA. The definitions of SOA are diverse. Most are complementary and do not conflict with each other. SOA has a variety of definitions because the definition is often tuned to a specific audience, as explaining SOA to a CEO is different from explaining SOA to a programmer. The term service orientation is often used synonymously with SOA, but just like SOA it has a wide range of interpretations. Service orientation is broader and represents a way of thinking about services in the context of business and IT. This book makes no distinction between SOA and service orientation and in some cases may use the two terms synonymously.
An agreed-upon definition for SOA eludes the industry. Anyone reading Wikipedia's definition page for SOA will see the challenges of trying to gain consensus on an SOA definition. Standards bodies, the OASIS group, and the Open Group have provided complementary but different SOA definitions. Presented with a blank sheet of paper, an artist sees a canvas. A poet might fill it with verse. An engineer seizes the opportunity to make a paper plane. Kids may see it as a future pile of spit wads. SOA is that blank sheet of paper.
To the chief information officer (CIO), SOA is a journey that promises to reduce the lifetime cost of the application portfolio, maximize return on investment (ROI) in both application and technology resources, and reduce lead times in delivering solutions to the business.
To the business executive, SOA is a set of services that can be exposed to their customers, partners, and other parts of the organization. Business capabilities, function, and business logic can be combined and recombined to serve the needs of the business now and tomorrow. Applications serve the business because they are composed of services that can be quickly modified or redeployed in new business contexts, allowing the business to quickly respond to changing customer needs, business opportunities, and market conditions.
To the business analyst, SOA is a way of unlocking value, because business processes are no longer locked in application silos. Applications no longer operate as inhibitors to changing business needs.
To the chief architect or enterprise architect, SOA is a means to create dynamic, highly configurable and collaborative applications built for change. SOA reduces IT complexity and rigidity. SOA becomes the solution to stop the gradual entropy that makes applications brittle and difficult to change. SOA reduces lead times and costs because reduced complexity makes modifying and testing applications easier when they are structured using services.
To the IT architect, SOA is the architectural solution for integrating diverse systems by providing an architectural style that promotes loose coupling and reuse. Many IT architects think they have seen this style before with earlier architectural initiatives such as DCE, the Distributed Computing Environment, and CORBA, the Common Object Request Broker Architecture.
To the developer, SOA is a programming model or paradigm where web services and contracts becomes a dominant design for interoperability. It is a web service when it uses a Web Service Description Language (WSDL) or equivalent specification for describing the service. Web services enable organizations to communicate information, using messages, without intimate knowledge of each other's IT systems.
Delivering on the promises of SOA (improved business agility, maximized ROI, reduced IT complexity and rigidity, reduced costs, reduced lead times, reduced risk, new opportunities to deliver value, increased participation in value networks, and incremental implementation) requires you take a holistic view of SOA. If we limit the view of SOA to a single stakeholder (e.g., IT architect, developer, or business analyst) the benefits will not accrue because SOA then just becomes one in a long list of overhyped technologies rather than a novel approach to building flexible business solutions.
2. Is SOA an Architectural Style?
SOA is often seen as an architectural style that has been around for years. Figure 1.1 shows the architectural style of SOA. In this scenario, a service consumer invokes or uses a service. The service consumer uses the service description to obtain necessary information about the provider service (e.g., account service) to be consumed. The service description provides the binding information so the consumer can connect to the service, and the description identifies the various operations (e.g., open or close account) available from the provider service. A broker can be used to find the service using a registry that houses information about the service and its location.
)
Figure 1.1 SOA as an architecture style
In Figure 1.1, it is difficult to determine how the architecture style of SOA enables the strategic benefits of SOA, such as lowering the lifetime cost of an application or bringing faster time to market or making applications resilient to change. SOA as an architectural style often makes an SOA project solely an IT endeavor where the strategic business benefits of SOA no longer become the focus or measured outcomes. Benefits of process flexibility, time-to-market savings, lower costs, and others can be achieved with SOA, but only if we holistically adopt all stakeholder views of SOA and its application and pursue SOA adoption accordingly. When pundits, architects, consultants, or executives define SOA as a pure technology play or as solely an architectural style, they relegate it to the realm of IT science projects, overhyped technologies, and a marketing strategy rather than a novel approach to building flexible business solutions.
An understanding of SOA is enhanced with the next question and answer. By looking at the SOA building blocks of SOA, you can gain a fuller understanding of what SOA is and how to realize its promised benefits.
3. What Are the Fundamental Constructs (the DNA) of SOA?
The most basic construct or building block of SOA is a service. Software engineering over the years has evolved from procedural to structured programming to object-oriented programming to component-based development and now to service oriented. Figure 1.2 illustrates the different levels of abstraction from objects to services. Each evolution of abstraction builds on the previous, and SOA embraces the best practices of object and component development.
)
Figure 1.2 Levels of abstraction
To see architectural style of SOA, refer to Figure 1.1. That illustration shows the fundamental constructs of SOA, such as the service consumer and the service provider and their relationship. The consumer invokes a service, the business functionality, by contract. The provider of the service defines the contract as a service description. An intermediary, such as a broker, uses a registry to find or search for published services. Service consumer, service provider, service description, service broker, and a registry are all part of the DNA of SOA.
A service in SOA is the logical, self-contained business function. Services in SOA have the following attributes:
- Stateless: SOA services neither remember the last thing they were asked to do nor do they care what the next is. Services are not dependent on the context or state of other services, only on their functionality. Talking on the telephone is stateful, whereas posting a letter is stateless. The World Wide Web provides an excellent example, where each request from a user for a web page or URL results in the requested pages being served, but without the web server remembering the request later. Each request or communication is discrete and unrelated to requests that precede or follow it.
- Discoverable: A service must be discoverable by potential consumers of the service. After all, if a service is not known to exist, it is unlikely ever to be used. Services are published or exposed by service providers in the SOA service directory, from which they are discovered and invoked by service consumers.
- Self-describing: The SOA service interface describes, exposes, and provides an entry point to the service. The interface contains all the information a service consumer needs to discover and connect to the service, without ever requiring the consumer to understand (or even see) the technical implementation details.
- Composable: SOA services are, by nature, composite. They can be composed from other services and, in turn, can be combined with other services to compose new business solutions.
- Loose coupling: Loose coupling allows the concerns of application features to be separated into independent pieces. This separation of concern provides a mechanism for one service to call another without being tightly bound to it. Separation of concerns is achieved by establishing boundaries, where a boundary is any logical or physical separation that delineates a given set of responsibilities. For example, an account service has open account, authorization, and audit features representing delineations of responsibilities and three separations of concerns.
- Governed by policy: Services are built by contract. Relationships between services (and between services and service domains) are governed by policies and service-level agreements (SLAs), promoting process consistency and reducing complexity.
- Independent location, language, and protocol: Services are designed to be location transparent and protocol/platform independent (generally speaking, accessible by any authorized user, on any platform, from any location).
In addition, services in a service-oriented architecture typically have the following characteristics:
- Coarse-grained: Services are typically coarse-grained business functions. Granularity is a statement of functional richness for a service—the more coarse-grained a service is, the richer the function offered by the service. Coarse-grained services reduce complexity for system developers by limiting the steps necessary to fulfill a given business function, and they reduce strain on system resources by limiting the "chattiness" of the electronic conversation. Applications by nature are coarse-grained because they encompass a large set of functionality; the components that comprise applications would be fine-grained. Similarly, within an application, a service such as "get account information" (which returns name, account number, and address) could be described as coarse-grained, whereas a service to "get account number" could be described as fine-grained.
- Asynchronous: Asynchronous communication is not required of an SOA service, but it does increase system scalability through asynchronous behavior and messaging techniques. Unpredictable network latency and high communications costs can slow response times in an SOA environment, due to the distributed nature of services. Asynchronous behavior and messaging allow a service to issue a service request and then continue processing until the service provider returns a response.
Viewed from the top down, SOA comprises the following constructs, as illustrated in Figure 1.3: consumer, business processes, services, components, information, rules, and policies. Consumers allow invocation or composition of services at the consumer layer through social software, mashups, business processes, or other systems. Business processes represent the flows of activities required to complete a business process; they are compositions of services targeted to achieve business goals. Services are the main structuring element required by a service consumer and are provided by the service provider. Services offer functionality and quality of service, both of which are externalized within service descriptions and policies. Services can be composed of other services, thus making them composite services. Components realize not only the functionality of the services they expose but also ensure their quality of service. Information flows between the layers (for example, consumer, process, and service) and within a layer. Lastly, rules and policies exist for services, components, and flows.
)
Figure 1.3 Top-down view of SOA constructs
Although objects are illustrated in Figure 1.3, the word object does not imply an implementation of object orientation, because the object can easily be a procedural subroutine implemented in a multitude of languages as easily as it can be implemented in a object-oriented programming language. SOA must have services and components that realize the services. Processes or flows may string services together to fulfill a step or activity of a business process. For example a transfer of funds service may string together both a debit and credit account service.
There is also a technology view of SOA. Technology enables SOA, makes it efficient, and optimizes the implementation, but SOA is not defined by the technologies chosen for implementation. Instead, SOA is defined by providing a uniform means to offer, discover, interact with, and use capabilities (services) to produce desired effects consistent with measurable expectations.
The major technologies associated with SOA include business-focused tools, software construction tools, and middleware technologies. Figure 1.4 illustrates the basic technology building blocks for SOA. Tools are required for SOA addressing design-time and runtime scenarios. Business stakeholders use business-focused tools for modeling and analysis of business processes and flows, and they will also use business activity monitoring technology to gain insights into business performance of processes and workflow. IT practitioners use a set of tools for development of business applications and for managing the operating environment addressing integration, monitoring, and security.
)
Figure 1.4 Business and IT tools for SOA
The DNA of SOA will most likely be further investigated and defined by standards groups actively involved in defining an SOA ontology. For example, see www.opengroup.org/projects/soa-ontology/. Such an ontology will address SOA key concepts, including services, service contracts, service interfaces, composition (orchestration, choreography, and collaboration), processes, service compositions, policies, and events. Each of these makes up the DNA of SOA.
4. What Is the Difference Between a Web Service and an SOA Service?
The distinction between business services or SOA services versus a web service is not often articulated, and many equate the two as being the same. SOA services can be realized as web services, but not all web services are equal to SOA services. Web services represent the use of both a published standard and a set of technologies for invocation and interoperability. SOA services are services that fulfill a key step or activity of a business process and can be described as business services and are often exposed as web services.
Figure 1.3 illustrates both an SOA service and a web service. The picture shows the difference between SOA and web services at runtime (i.e., implementation level) and at design time. The web service is illustrated on the right side of Figure 1.5, specifically the Web Services Description Language (WSDL) and its attributes such as port types and operations. The attribute that makes it a web service is the use of WSDL or equivalent.
)
Figure 1.5 SOA service and web service
In design, we identify and specify a service that provides the design, or we identify and specify interfaces that include method specifications. The combination of the definition of the method and the interface at design time is what we refer to as a service from an SOA perspective. Use cases can be used to capture the functional requirements for a service. Figure 1.5 contrasts the differences between a service in SOA and a web service. Both SOA services and web services are part of the DNA of SOA.
In an SOA, business processes, activities, and workflow are broken down into constituent functional elements called services. They can be accessed and used directly by applications, or they can be mixed and matched with other services to create new business capabilities. Business services or SOA services are reusable business capabilities. Examples in banking include open account or change address. For transportation, it might be get reservation or hold reservation, and with loan processing, get loan, apply for loan, and update address are examples of business services. Business processes are also key constructs of SOA, part of its DNA.
5. What Makes a Project an SOA Implementation?
The deployment of services makes a project an SOA implementation, where a service is defined in the preceding answer as a web service or an SOA service. The use of the Web Service Description Language (WSDL) or equivalent makes a service a web service. An SOA service must satisfy the criteria described in the Answer 2; namely, an SOA service must be stateless; discoverable; self-describing; composable; loosely coupled; governed; and independent of location, language, or protocol. That is, the use of services alone makes the project or implementation an SOA implementation. However, an SOA implementation may not accrue the desired benefits of SOA around cost savings, reuse, time to market, or flexibility.
Services can have different levels of maturity. For example, services can be ad hoc in their design and implementation where a WSDL façade is implemented to make function accessible to other systems or applications. Services can also be architected where service modeling and governance are used to maximize service reuse.
The implementation of SOA technologies without a deployment of one or more services could also be defined as an SOA implementation. This would be atypical because middleware and infrastructure implementations (e.g., a registry or enterprise service bus) would be implemented in conjunction with the deployment of services.
Just as services have different levels of maturity, so do SOA adoptions within an organization. Some SOA adoptions require a program of projects to address a journey of increasing maturity to achieve strategic SOA goals of building systems for change, infusing flexibility as an attribute of systems, or reducing the lifetime costs of applications and infrastructure. In this case, the program comprises a series of SOA projects that incrementally raise the maturity of SOA in an organization and along the way enable the realization of the strategic SOA benefits.
Often, because of overselling of SOA, organization leaders, managers, and executives wrongly believe that the benefits of SOA automatically accrue when an SOA implementation occurs. SOA has varied and diverse definitions, and hence its implementations are equally varied. So, organizations seeking to accrue any of the promised benefits of SOA must do more than focus on SOA implementations. That is, each expected benefit of SOA requires a different level of SOA maturity. For example, if the goal is only to reduce the cycle time of a business process that deals with external partners, exposing web services may be the only necessary SOA adoption. However, if the business goal is to reduce time to market for new products, this requires a broader adoption of SOA that addresses reusable services, structuring of applications using services, improving integration using services, and aspects of SOA governance to address service sharing, funding, and ownership.