Related Topics: Cloud Computing, SOA Best Practices Digest, SOA & WOA Magazine, Microservices Journal

Book Excerpt

Book Excerpt: Service-Oriented Computing Fundamentals

Service-oriented computing is an umbrella term that represents a new generation distributed computing platform

SOA Manifesto
Historically, the term "service-oriented architecture" (or "SOA") has been used so broadly by the media and within vendor marketing literature that it has almost become synonymous with service-oriented computing itself. The SOA Manifesto (published at is a formal declaration authored by a diverse working group comprised of industry thought leaders during the 2nd International SOA Symposium in Rotterdam in 2009. This document establishes, at a high level, a clear separation of service-oriented architecture and service-orientation in order to address the ambiguity that had been causing confusion in relation to the meaning of the term "SOA."

The Annotated SOA Manifesto is published at and in Appendix E of this book. This version of the SOA Manifesto is recommended reading as it elaborates on statements made in the original SOA Manifesto.

Cloud Computing
Cloud computing
is a specialized form of distributed computing that introduces utilization models for remotely provisioning scalable and measured IT resources. The primary benefits associated with cloud computing are:

  • Reduced Investment and Proportional Costs - Cloud consumers that use cloud-based IT resources can generally lease them with a pay-for-use model, which allows them to pay a usage fee for only the amount of the IT resource actually used, resulting in directly proportional costs. This gives an organization access to IT resources without having to purchase its own, resulting in reduced investment requirements. By lowering required investments and incurring costs that are proportional to their needs, cloud consumers can scale their IT enterprise effectively and pro-actively.
  • Increased Scalability - IT resources can be flexibly acquired from a cloud provider, almost instantaneously and at a wide variety of usage levels. By scaling with cloud-based IT resources, cloud consumers can leverage this flexibility to increase their responsiveness to planned and unforeseen changes.
  • Increased Availability and Reliability - Cloud providers generally offer resilient IT resources for which they are able to guarantee high levels of availability. Cloud environments can be based on a modular architecture that provides extensive failover support to further increase reliability. Cloud consumers that lease access to cloud-based IT resources can therefore benefit from increased availability and reliability.

When appropriate, these benefits can help realize the strategic goals of service-oriented computing by extending and enhancing service-oriented architectures and increasing the potential of realizing certain service-orientation principles.

IT Resources
An IT resource is a broad term to refer to any physical or virtual IT-related artifact (software or hardware). For example, a physical server, a virtual server, a database, and a service implementation are all forms of IT resources.

Even though a service is considered an IT resource, it is important to acknowledge that a service architecture will commonly encapsulate and connect to other IT resources. This distinction is especially important in cloud-based environments, where a cloud service is classified as a remotely accessible IT resource that may encompass and depend on various additional cloud-based IT resources that are only accessible from within the cloud.

A cloud is a distinct IT environment designed for the purpose of remotely provisioning scalable and measured IT resources. In order to remotely provision scalable and measured IT resources in an effective manner, an IT environment requires a specific set of characteristics. These characteristics need to exist to a meaningful extent for the IT environment to be considered an effective cloud.

  • On-Demand Usage - This characteristic allows for the usage of self-provisioned IT resources to be automated so that no further human involvement by the provider or consumer of these resources is required.
  • Ubiquitous Access - This is the ability for a cloud-based IT resource to be widely accessible.
  • Multitenancy - Multitenancy is the characteristic of a software program that enables an instance of the program to serve different consumers (tenants), each of which is isolated from the other.
  • Elasticity - This is the ability of a cloud to enable its consumers to scale cloud-based IT resources up or down, as required.
  • Measured Usage - This represents the ability of a cloud platform to keep track of the usage of its IT resources by its consumers.
  • Resilient Computing - This characteristic represents a form of failover that distributes redundant implementations of IT resources across physical locations.

Services that reside in cloud environments are referred to as cloud services or cloud-based services. Services are one form of IT resource hosted by clouds.

Figure 9: The symbol used to represent a cloud environment.

The term on-premise is used as a qualifier to indicate that a service or IT resource (or some other artifact) resides within an internal IT enterprise environment, as opposed to a cloud-based environment. The use of "on-premise" within this book is primarily associated with discussions pertaining to cloud computing issues. By default, coverage of services, architectures, infrastructure, and other types of implementations are assumed to be on-premise, unless otherwise qualified.

Figure 10: A service shown on-premise, within an IT enterprise (left) and a cloud-based service, deployed within a cloud (right).

Cloud Deployment Models
A cloud deployment model represents a specific type of cloud environment, primarily distinguished by ownership and size.

There are four common deployment models:

  • Public Cloud - A public cloud is a publically accessible cloud environment owned by a third-party cloud provider.
  • Community Cloud -A community cloud is similar to a public cloud except that its access is limited to a specific community of cloud consumers.
  • Private Cloud - A private cloud is owned by a single organization.
  • Hybrid Cloud - A hybrid cloud is a cloud environment of two or more different cloud deployment models.

Variations of these models can also exist.

Cloud Consumers and Cloud Providers
The organization that uses cloud services is referred to as the cloud consumer, whereas the organization that owns and offers cloud IT resources and services is the cloud provider. With private clouds the cloud consumer and cloud provider can be the same organization, in which case these roles are assumed by departments or groups within the organization.

Cloud Delivery Models
A cloud delivery model represents a specific combination of IT resources offered by a cloud provider.

Three common delivery models are used:

  • Infrastructure-as-a-Service (IaaS) - The IaaS delivery model provides a self-­contained IT environment comprised of infrastructure-centric IT resources.
  • Platform-as-a-Service (PaaS) - The PaaS delivery model provides a pre-defined cloud environment with already deployed and configured IT resources suitable for the development and deployment of applications.
  • Software-as-a-Service (SaaS) - The SaaS delivery model generally represents a product that exists as a shared cloud service offered by a cloud provider to cloud consumers.

Variations of these models can also exist.

Service Models
A service model is a classification used to indicate that a service belongs to one of several predefined types based on the nature of the logic it encapsulates, the reuse potential of this logic, and how the service may relate to domains within its enterprise.

The following three service models are common to most enterprise environments and therefore common to most SOA projects:

  • Task Service - A service with a non-agnostic functional context that generally corresponds to single-purpose, parent business process logic. A task service will usually encapsulate the composition logic required to compose several other services in order to complete its task.
  • Entity Service - A reusable service with an agnostic functional context associated with one or more related business entities (such as invoice, customer, claim, etc.). For example, a Purchase Order service has a functional context associated with the processing of purchase order-related data and logic.
  • Utility Service - Also a reusable service with an agnostic functional context, but this type of service is intentionally not derived from business analysis specifications and models. It encapsulates low-level technology-centric functions, such as notification, logging, and security processing.

Service models play an important role during service-oriented analysis and service-oriented design phases. Although the just listed service models are well established, it is not uncommon for an organization to create its own service models. Often these new classifications tend to be derived from one of the aforementioned fundamental service models.

Agnostic Logic and Non-Agnostic Logic
The term "agnostic" originated from Greek and means "without knowledge." Therefore, logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Because knowledge specific to single purpose tasks is intentionally omitted, agnostic logic is considered multi-purpose. On the flipside, logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic.

Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be repurposed. Because agnostic logic is expected to be multi-purpose, it has reuse potential and therefore forms the basis of shared service logic. Once reusable, this logic is truly multi-purpose in that it, as a single software program (or service), can be used to automate multiple business processes.

Non-agnostic logic does not have these types of expectations. It is deliberately designed as a single-purpose software program (or service) and therefore has different characteristics and requirements.

Service Composition
A service composition is an aggregate of services collectively composed to automate a particular task or business process. To qualify as a composition, at least two participating services plus one composition initiator need to be present. Otherwise, the service interaction only represents a point-to-point exchange.

Figure 11: A service composition comprised of four services. The arrows indicate a sequence of modeled message exchanges. Note arrow #5 representing a one-way, asynchronous data delivery from Service A to Service D.

Service compositions can be classified into primitive and complex variations. In early service-oriented solutions, simple logic was generally implemented via point-to-point exchanges or primitive compositions. As the surrounding technology matured, complex compositions became more common.

Much of the service-orientation design paradigm revolves around preparing services for effective participation in numerous complex compositions - so much so that the Service Composability design principle exists, dedicated solely to ensuring that services are designed in support of repeatable composition.

Service Inventory
A service inventory is an independently standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise. When an organization has multiple service inventories, this term is further qualified as domain service inventory.

Service inventories are typically created through top-down delivery processes that result in the definition of service inventory blueprints. The subsequent application of service-orientation design principles and custom design standards throughout a service inventory is of paramount importance so as to establish a high degree of native inter-service interoperability. This supports the repeated creation of effective service compositions in response to new and changing business requirements.

Service Portfolio
Service portfolio
(also commonly referred to as a "service catalog") is a separate term used to represent a set of the services within a given IT enterprise. The distinction between service inventory and service portfolio is important as these and related terms are used within different contexts, as follows:

  • Service inventory represents a collection of implemented services that are independently owned and governed.
  • The Service Inventory Analysis is a modeling process by which service candidates are defined for a new or existing service inventory.
  • A service inventory blueprint is a technical specification that represents the result of having performed a service inventory analysis. Subsequent iterations of the service inventory analysis process can expand or further refine a service inventory blueprint.
  • The term "service portfolio" has a less specific definition than service inventory in that it can represent all or a subset of the services within an IT enterprise.
  • A service portfolio often exists as a high-level documentation of services used for planning purposes.
  • A service portfolio most commonly encompasses one or multiple service inventories.

Service portfolio management is the practice of planning the definition, delivery, and evolution of collections of services.

Service Candidate
When conceptualizing services during the service-oriented analysis and service modeling processes, services are defined on a preliminary basis and still subject to a great deal of change and refinement before they are handed over to the Service-Oriented Design project stage responsible for producing physical service contracts. The term service candidate is used to help distinguish a conceptualized service from an actual implemented service.

Figure 12: The Get operation (right) is first modeled and then forms the basis of the actual operation definition within a WSDL document (left).

Service Contract
A service contract is comprised of one or more published documents that express meta information about a service. The fundamental part of a service contract consists of the documents that express its technical interface. These form the technical service contract, which essentially establishes an API into the functionality offered by the service via its capabilities.

When services are implemented as Web services, the most common service description documents are the WSDL definition, XML Schema definition, and WS-Policy definition. A Web service generally has one WSDL definition, which can link to multiple XML Schema and policy definitions. When services are implemented as components, the technical service contract is comprised of a technology-specific API.

Services implemented as REST services are commonly accessed via a uniform contract, such as the one provided by HTTP. Service contracts are depicted differently depending on whether a uniform contract is involved.

Figure 13: The standard symbol used to display a service contract (left) and one that is accessed via a uniform contract (right)

A service contract can be further comprised of human-readable documents, such as a Service Level Agreement (SLA) that describes additional quality-of-service features, behaviors, and limitations. Several SLA-related requirements can also be expressed in machine-readable format as policies.

Figure 14: The common documents that comprise the technical Web service contract, plus a human-readable SLA

Within service-orientation, the design of the service contract is of paramount ­importance-so much so, that the Standardized Service Contract (475) design principle and the aforementioned service-oriented design process are dedicated solely to the standardized creation of service contracts.

Service-Related Granularity
When designing services, there are different granularity levels that need to be taken into consideration, as follows:

  • Service Granularity - This level of granularity represents the functional scope of a service. For example, fine-grained service granularity indicates that there is little logic associated with the service's overall functional context.
  • Capability Granularity - The functional scope of individual service capabilities (operations) is represented by this granularity level. For example, a GetDetail capability will tend to have a finer measure of granularity than a GetDocument capability.
  • Constraint Granularity - The level of validation logic detail is measured by constraint granularity. The more coarse constraint granularity is, the less constraints (or smaller the amount of validation logic) a given capability will have.
  • Data Granularity - This granularity level represents the quantity of data processed. For example, from a Web service contract perspective, this corresponds to input, output, and fault messages. A fine level of data granularity is equivalent to a small amount of data.

Because the level of service granularity determines the functional scope of a service, it is usually determined during analysis and modeling stages that precede service contract design. Once a service's functional scope has been established, the other granularity types come into play and affect both the modeling and physical design of a service contract.

Figure 15: The four granularity levels that represent various characteristics of a service and its contract. Note that these granularity types are, for the most part, independent of each other.

SOA Design Patterns
A design pattern is a proven solution to a common design problem. The SOA design pattern catalog provides a collection of design patterns that provide practices and techniques for solving common problems in support of service-orientation.

Figure 16: SOA design patterns form a design pattern language that allows patterns to be applied in different combinations and in different sequences in order to solve various complex design problems.

SOA design patterns do not only pertain to the actual design of services and related environments. Many patterns represent solutions that are realized by the application of standards and technologies highly relevant to SOA governance. Throughout this book you will notice references to patterns as a supplemental resource that further formalizes a given solution. In some cases, an SOA design pattern is even the primary basis of an SOA governance precept.

Further Reading

  • Explanations of the service-oriented computing goals and benefits are available at and in Chapter 3 of SOA Principles of Service Design.
  • Explanations and definitions of concepts and terminology pertaining to cloud computing are available at
  • For information about SOA types and the distinct characteristics of the service-oriented technology architecture, see Chapter 4 of SOA Design Patterns.
  • Design principles are referenced throughout this book but represent a separate subject matter that is covered in SOA Principles of Service Design. Introductory coverage of service-orientation as a whole is also available at and all eight principle profile tables are provided in Appendix C of this book.
  • For a comparison of service-orientation and object-orientation concepts and principles, see Chapter 14 in SOA Principles of Service Design.
  • Numerous design patterns are referenced in the upcoming chapters. These patterns are part of a greater SOA design patterns catalog that was published in the book SOA Design Patterns. Pattern profiles are available online at the community site, and pattern profile tables for design patterns referenced in this book are further provided in Appendix D.
  • Definitions for the terms introduced in this chapter can also be found at
  • Read the Annotated SOA Manifesto in Appendix E (also published at for a formal, high level description of SOA and service-orientation.

See for additional reading resources, and visit and for additional educational resources.

•   •   •

"This excerpt is from the new book, ‘SOA Governance: Governing Shared Services On-Premise and in the Cloud', authored by Thomas Erl, Stephen G. Bennett, Benjamin Carlyle, Clive Gee, Robert Laird, Anne Thomas Manes, Robert Moores, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable, and Filippos Santas, published in the Prentice Hall Service-Oriented Computing Series from Thomas Erl, April 2011, ISBN 0138156751, Copyright 2011 SOA Systems Inc. For more info, please visit the publisher site or author site,

More Stories By Thomas Erl

Thomas Erl is a best-selling IT author and founder of Arcitura Education Inc., a global provider of vendor-neutral educational services and certification that encompasses the Cloud Certified Professional (CCP) and SOA Certified Professional (SOACP) programs from™ and® respectively. Thomas has been the world's top-selling service technology author for nearly a decade and is the series editor of the Prentice Hall Service Technology Series from Thomas Erl, as well as the editor of the Service Technology Magazine. With over 175,000 copies in print world-wide, his eight published books have become international bestsellers and have been formally endorsed by senior members of many major IT organizations and academic institutions. To learn more, visit:

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.