Chapter 3. Fundamental SOA Concepts
3.1 Basic Terminology and Concepts
This chapter describes fundamental terms and concepts associated with service-oriented computing.
3.1 Basic Terminology and Concepts
Definitions for the following terms used throughout this book are provided in this section:
• Service-Oriented Computing
• Service-Orientation
• Service-Oriented Architecture (SOA)
• SOA Manifesto
• Services
• Cloud Computing
• Service Models
• Service Inventory
• Service Portfolio
• Service Candidate
• Service Contract
• Service-Related Granularity
• SOA Design Patterns
Service-Oriented Computing
Service-oriented computing is an umbrella term that represents a distinct distributed computing platform. As such, it encompasses many things, including its own design paradigm and design principles, design pattern catalogs, pattern languages, and a distinct architectural model, along with related concepts, technologies, and frameworks.
Service-orientation emerged as a formal method in support of achieving the following goals and benefits (Figure 3.1) associated with service-oriented computing:
• Increased Intrinsic Interoperability – Services within a given boundary are designed to be naturally compatible so they can be effectively assembled and reconfigured in response to changing business requirements.
• Increased Federation – Services establish a uniform contract layer that hides underlying disparity, allowing them to be individually governed and evolved.
• Increased Vendor Diversification Options – A service-oriented environment is based on a vendor-neutral architectural model, allowing the organization to evolve the architecture in tandem with the business without being limited to proprietary vendor platform characteristics.
• Increased Business and Technology Alignment – Some services are designed with a business-centric functional context, allowing them to mirror and evolve with the business of the organization.
• Increased ROI – Most services are delivered and viewed as IT assets that are expected to provide repeated value that surpasses the cost of delivery and ownership.
• Increased Organizational Agility – New and changing business requirements can be fulfilled more rapidly by establishing an environment in which solutions can be assembled or augmented with reduced effort by leveraging the reusability and native interoperability of existing services.
• Reduced IT Burden – The enterprise as a whole is streamlined as a result of the previously described goals and benefits, allowing IT itself to better support the organization by providing more value with less cost and less overall burden.
Figure 3.1 The three goals on the right represent the target strategic benefits achieved when attaining the four goals on the left.
These goals collectively represent the target state we look to achieve when we consistently apply service-orientation to the design of software programs.
Note
The strategic goals of service-oriented computing are also commonly associated with SOA, as explained in the SOA Manifesto section.
Service-Orientation
Service-orientation is a design paradigm intended for the creation of solution logic units that are individually shaped to be collectively and repeatedly utilized in support of the realization of the specific strategic goals and benefits associated with service-oriented computing.
Solution logic designed in accordance with service-orientation can be qualified with “service-oriented,” and units of service-oriented solution logic are referred to as “services.” As a design paradigm for distributed computing, service-orientation can be compared to object-orientation or object-oriented design. Service-orientation has many roots in object-orientation and has been influenced by other industry developments, as seen in Figure 3.2.
Figure 3.2 Service-orientation is an evolutionary design paradigm that owes much of its existence to established design practices and technology platforms.
The service-orientation design paradigm is primarily comprised of eight specific design principles (Figure 3.3):
• Standardized Service Contract – “Services within the same service inventory are in compliance with the same contract design standards.”
• Service Loose Coupling – “Service contracts impose low service consumer coupling requirements and are themselves decoupled from their surrounding environment.”
• Service Abstraction – “Service contracts only contain essential information and information about services is limited to what is published in service contracts.”
• Service Reusability – “Services contain and express agnostic logic and can be positioned as reusable enterprise resources.”
• Service Autonomy – “Services exercise a high level of control over their underlying runtime execution environment.”
• Service Statelessness – “Services minimize resource consumption by deferring the management of state information when necessary.”
• Service Discoverability – “Services are supplemented with communicative metadata by which they can be effectively discovered and interpreted.”
• Service Composability – “Services are effective composition participants, regardless of the size and complexity of the composition.”
Figure 3.3 The repeated application of service-orientation principles to services that are delivered as part of a collection leads to a target state based on the manifestation of the strategic goals associated with service-oriented computing. Note that the container symbol represents a “service inventory,” which is defined later in this chapter.
Service-Oriented Architecture (SOA)
Service-oriented architecture is a technology architectural model for service-oriented solutions with distinct characteristics in support of realizing service-orientation and the strategic goals associated with service-oriented computing. Different types of service-oriented architecture can exist, depending on the scope of its application (Figure 3.4).
Figure 3.4 The layered SOA model establishes the four common SOA types: service architecture, service composition architecture, service inventory architecture, and service-oriented enterprise architecture. (These different architectural types are explained in detail in the SOA Design Patterns book.)
As a form of technology architecture, an SOA implementation can consist of a combination of technologies, products, APIs, supporting infrastructure extensions, and various other parts. The actual complexion of a deployed service-oriented architecture is unique within each enterprise as typified by the introduction of new technologies and platforms that specifically support the creation, execution, and evolution of service-oriented solutions. As a result, building a technology architecture with the SOA model establishes an environment suitable for solution logic that has been designed in compliance with service-orientation design principles.
Let’s briefly recap the terms service-oriented computing, service-orientation, and service-oriented architecture to clearly establish how they relate to each other and, specifically, how they lead to a definition of an SOA as follows:
• A set of strategic goals representing a specific target state is associated with service-oriented computing.
• Service-orientation is the paradigm that provides a proven method for achieving this target state.
• When we apply service-orientation to the design of software, we build units of logic called “services”.
• Service-oriented solutions are comprised of one or more services.
• To build successful service-oriented solutions, we need a distributed technology architecture with specific characteristics.
• These characteristics distinguish the technology architecture as being service-oriented. This is SOA.
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 almost became synonymous with service-oriented computing itself. The SOA Manifesto published at www.soa-manifesto.org 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 www.soa-manifesto.com and in Appendix D of this book. This version of the SOA Manifesto is recommended reading as it elaborates on statements made in the original SOA Manifesto.
Services
From a service-orientation perspective, a service is a unit of logic to which service-orientation has been applied to a meaningful extent. It is the application of service-orientation design principles that distinguishes a unit of logic as a service compared to units of logic that may exist solely as objects, components, Web services, REST services, or cloud-based services.
Subsequent to conceptual service modeling, service-oriented design and development stages implement a service as a physically independent software program with specific design characteristics that support the attainment of the strategic goals associated with service-oriented computing. Each service is assigned its own distinct functional context and is comprised of a set of capabilities related to this context. Therefore, a service can be considered a container of capabilities associated with a common purpose or functional context.
It is important to view and position SOA and service-orientation as being neutral to any one technology platform. By doing so, you have the freedom to continually pursue the strategic goals associated with service-oriented computing by leveraging on-going service technology advancements.
Any implementation technology that can be used to create a distributed system may be suitable for the application of service-orientation. In addition to Web services and REST services, distributed components can also be used to create legitimate service-oriented solutions (Figure 3.5).
Figure 3.5 These are the symbols used to represent a component. The symbol on the left is a generic component that may or may not have been designed as a service, whereas the symbol on the right highlights the embedded service contract, and is therefore labeled to indicate that it has been designed as a service.
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 that 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 proactively.
• 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 foreseen 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 which may encompass and depend on various additional cloud-based IT resources that are only accessible from within the cloud.
Service Models
A service model is a classification used to indicate that a service belongs to one of several pre-defined 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, or claim. For example, a Purchase Order service has a functional context associated with the processing of purchase order-related data and logic.
• Utility Service – A reusable service with an agnostic functional context intentionally separate from business analysis specifications and models. A utility service 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 aforementioned set of service models is well established, it is not uncommon for an organization to create its own service models that are often derived from established 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. Alternatively, 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 is subject to the Service Reusability principle with the intention of turning it into highly reusable logic. Logic made reusable is truly multi-purpose in that, as a single software program or service, it can be used to help 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 with different characteristics and requirements.
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 (Figure 3.6).
Figure 3.6 Services (top) are delivered into a service inventory (right) from which service compositions (bottom) are drawn.
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:
• A 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 are 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 a service that has actually been implemented.
Service Contract
A service contract expresses the technical interface of a service. It can be comprised of one or more published documents that express meta information about a service, which essentially establish 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 WS-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 accessed via a uniform contract, such as the one provided by HTTP and Web media types. Service contracts are depicted differently depending on whether a uniform contract is involved.
A service contract can be further comprised of human-readable documents, such as a service-level agreement (SLA) that describes additional quality-of-service guarantees, behaviors, and limitations. Several SLA-related requirements can also be expressed in machine-readable format as policies.
Within service-orientation, the design of the service contract is of paramount importance, so much so that the Standardized Service Contract 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 represents the functional scope of a service. For example, fine-grained service granularity indicates that there is a small quantity of logic associated with the service’s overall functional context.
• Capability Granularity – The functional scope of individual service capabilities 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. For example, the more coarse the constraint granularity is, the less constraints (or smaller the amount of data validation logic) a given capability will have.
• Data Granularity – This granularity level represents the quantity of data processed. For example, 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 3.7).
Figure 3.7 The four granularity levels represent various characteristics of a service and its contract. Note that these granularity types are, for the most part, independent of each other.
Granularity is generally measured in terms of fine and coarse levels. It is worth acknowledging that the use of the terms “fine-grained” and “coarse-grained” is highly subjective. What may be fine-grained in one case may not be in another. The point is to understand how these terms can be applied when comparing parts of a service or when comparing services with each other.
Service Profiles
The document used to record details about a service throughout its lifecycle is the service profile (Figure 3.8). A service profile is typically maintained by the owner or custodian of a service and is based on a template that is standardized throughout a service inventory.
Figure 3.8 A service profile is generally created when a service is first conceptualized, and is then updated and maintained throughout subsequent lifecycle phases.
SOA Design Patterns
A design pattern is a proven solution to a common design problem. The SOA design patterns catalog provides a collection of design patterns (Figure 3.9) that provide practices and techniques for solving common problems in support of service-orientation.
Figure 3.9 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.
3.2 Further Reading
• Explanations of the service-oriented computing goals and benefits are available at www.serviceorientation.com and in Chapter 3 of SOA Principles of Service Design.
• 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 www.serviceorientation.com and all eight principle profile tables are provided in Appendix B of this book.
• For a comparison of service-orientation and object-orientation concepts and principles, see Chapter 14 in SOA Principles of Service Design.
• For an explanation of how SOA design patterns related to service-orientation design principles, see Chapter 5 in the SOA Design Patterns book.
• For general coverage of SOA project stages and associated organization roles and governance controls, see SOA Governance: Governing Shared Services On-Premise and in the Cloud.
• For detailed coverage of service-oriented analysis and service-oriented design process steps, see Service-Oriented Architecture: Concepts, Technology, and Design.
• Definitions for the terms introduced in this chapter can also be found at www.soaglossary.com.
• Read the Annotated SOA Manifesto in Appendix D (also published at www.soa-manifesto.com) for a high-level description of SOA and service-orientation (without references to specific principles or patterns).
See www.servicetechbooks.com for additional reading resources.