- 1 Service
- 2 The Service-Orientation Design Paradigm
- 3 Origins and Influences of Service-Orientation
In the every day world around us services are and have been commonplace for as long as civilized history has existed. Any person carrying out a distinct task in support of others is providing a service. Any group of individuals collectively performing a task in support of a larger task is also demonstrating the delivery of a service.
Figure: Three individuals, each capable of providing a distinct service.
Similarly an organization that carries out tasks associated with its purpose or business, is also providing a service. As long as the task or function being provided is well defined and can be relatively isolated from other associated tasks it can be distinctly classified as a service.
Figure: A company that employs these three people can compose their capabilities to carry out its business.
Certain baseline requirements exist to enable a group of individual service providers to collaborate in order to collectively provide a larger service. The above figure, for example, displays a group of employees that each provide a service for ABC Delivery. Even though each individual contributes a distinct service, for the company to function effectively, its staff also needs to have fundamental, common characteristics, such as availability, reliability, and the ability to communicate using the same language. With all of this in place, these individuals can be composed into a productive working team. Establishing these types of baseline requirements is a key goal of service-orientation.
Services in Business Automation
In the world of SOA and service-orientation the term “service” is not generic. It has specific connotations that relate to a unique combination of design characteristics. When solution logic is consistently built as services and when services are consistently designed with these common characteristics, service-orientation is successfully realized throughout an environment.
For example, one of the primary service design characteristics explored as part of this study of service-orientation is reusability. A strong emphasis on producing solution logic in the format of services that are positioned as highly generic and reusable enterprise resources gradually transitions an organization to a state where more and more of its solution logic becomes less dependent on and more agnostic to any one purpose or business process. Repeatedly fostering this characteristic within services eventually results in wide-spread reuse potential.
Consistently realizing specific design characteristics requires a set of guiding principles. This is what the service-orientation design paradigm is all about.
Services are Collections of Capabilities
When we discuss services, it is important to remember that a single service can provide a collection of capabilities. They are grouped together because they relate to a functional context established by the service. The functional context of the service illustrated in the figure below, for example, is that of “shipment.” Therefore, this particular service provides a set of capabilities associated with the processing of shipments.
Figure: Much like a human, an automated service can provide multiple capabilities.
A service can essentially act as a container of related capabilities. It is comprised of a body of logic designed to carry out these capabilities and a service contract that expresses which of its capabilities are made available for public invocation.
Note that when we make reference to service capabilities on this site, we are specifically focused on those that are defined as part of the service contract. When services are implemented as components these capabilities are typically referred to as “methods,” and when they are expressed as part of a Web service contract, they are called “operations.”
The Service-Orientation Design Paradigm
As we established on the Fundamental Design Terminology and Concepts page, a design paradigm is an approach to designing solution logic. When building distributed solution logic, design approaches revolve around a software engineering theory known as the “separation of concerns.” In a nutshell, this theory states that a larger problem is more effectively solved when decomposed into a set of smaller problems or concerns. This gives us the option of partitioning solution logic into capabilities, each designed to solve an individual concern. Related capabilities can be grouped into units of solution logic.
The fundamental benefit to solving problems this way is that a number of the solution logic units can be designed to solve immediate concerns while still remaining agnostic to the greater problem. This provides the constant opportunity for us to reutilize the capabilities within those units to solve other problems as well.
Different design paradigms exist for distributed solution logic. What distinguishes service-orientation is the manner in which it carries out the separation of concerns and how it shapes the individual units of solution logic. Applying service-orientation to a meaningful extent results in solution logic that can be safely classified as “service-oriented” and units that qualify as “services.” To understand exactly what that means requires an appreciation of the strategic goals of service-oriented computing combined with knowledge of the following service-orientation design principles:
– Standardized Service Contract
– Service Loose Coupling
– Service Abstraction
– Service Reusability
– Service Autonomy
– Service Statelessness
– Service Discoverability
– Service Composability
Figure: Each of the service-orientation principles contributes to the strategic goals and benefits associated with service-oriented computing.
Origins and Influences of Service-Orientation
It is often said that the best way to understand something is to gain knowledge of its history. Service-orientation, by no means, is a design paradigm that just came out of nowhere. It is very much a representation of the evolution of IT and therefore has many roots in past paradigms and technologies. At the same time, it is still in a state of evolution itself and thereby still subject to influences from on-going trends and movements.
Figure: By tracing the primary influences of service-orientation several of its roots can be identified.
The sections that follow describe some of the more prominent origins and thereby help clarify how service-orientation can relate to and even help further some of the goals from past paradigms.
In the 1990s the IT community embraced a design philosophy that would lead the way in defining how distributed solutions were to be built. This paradigm was object-orientation, and it came with its own set of principles, the application of which helped ensure consistency across numerous environments. These principles defined a specific type of relationship between units of solution logic classified as objects, which resulted in a predictable set of dynamics that ran through entire solutions.
Service-orientation is frequently compared to object-orientation, and rightly so. The principles and patterns behind object-oriented analysis and design represent one of the most significant sources of inspiration for this paradigm. In fact, a subset of service-orientation principles (service reusability, service abstraction, and service composability, for example) can be directly traced back to their object-oriented counterparts. What distinguishes service-orientation, though, are the parts of the object-oriented school of thought that were left out and the other principles that were added. See Chapter 14 in SOA: Principles of Service Design for a comparative analysis of concepts and principles associated with these two design approaches.
Even though service-orientation as a paradigm and SOA as a technology architecture are each implementation-neutral, their association with Web services has become commonplace – so much so that the primary SOA vendors have shaped their respective platforms around the utilization of Web services technology. Although service-orientation remains a fully abstract paradigm, it is one that has historically been influenced by the SOA platforms and roadmaps produced by these vendors. As a result, the Web services framework has inspired and promoted several service-orientation principles, including Service Abstraction, Service Loose Coupling, and Service Composability.
Business Process Management (BPM)
BPM places a significant emphasis on business processes within the enterprise both in terms of streamlining process logic to improve efficiency and also to establish processes that are adaptable and extensible so that they can be augmented in response to business change.
The business process layer represents a core part of any service-oriented architecture. From a composition perspective, it usually assumes the role of the parent service composition controller. The advent of orchestration technology reaffirmed this role from an implementation perspective.
A primary goal of service-orientation is to establish a highly agile automation environment fully capable of adapting to change. This goal can be realized by abstracting business process logic into its own layer, thereby alleviating other services from having to repeatedly embed process logic.
While service-orientation itself is not as concerned with business process reengineering, it fully supports process optimization as a primary source of change for which services can be recomposed.
Enterprise Application Integration (EAI)
Integration became a primary focal point in the late 90’s, and many organizations were ill prepared for it. Numerous systems were built with little thought given to how data could be shared outside of the system boundary. As a result, point-to-point integration channels were often created when data sharing requirements emerged. This led to well known problems associated with a lack of stability, extensibility, and inadequate interoperability frameworks.
EAI platforms introduced middleware that allowed for the abstraction of proprietary applications through the use of adapters, brokers, and orchestration engines. The resulting integration architectures were, in fact, more robust and extensible. However, they also became notorious for being overwhelmingly complex and expensive, as well as requiring long-term commitments to the middleware vendor’s platform and roadmap.
The advent of the open Web services framework and its ability to fully abstract proprietary technology changed the face of integration middleware. Vendor ties could be broken by investing in mobile services as opposed to proprietary platforms, and organizations gained more control over the evolution of their integration architectures.
Several innovations that became popularized during the EAI era were recognized as being useful to the overall goals associated with building SOA using Web services. One example is the broker component, which allows for services using different schemas representing the same type of data to still communicate through runtime transformation. The other is the orchestration engine, which can actually be positioned to represent an entire service layer within larger SOA implementations. These parts of the EAI platform support several service-orientation principles, including Service Abstraction, Service Statelessness, Service Loose Coupling, and Service Composability.
Aspect-Oriented Programming (AOP)
A primary goal of AOP is to approach the separation of concerns with the intent of identifying specific concerns that are common to multiple applications or automation scenarios. These concerns are then classified as “cross-cutting,” and the corresponding solution logic developed for cross-cutting concerns becomes naturally reusable.
Aspect-orientation emerged from object-orientation by building on the original goals of establishing reusable objects. Although not a primary influential factor of service-orientation, AOP does demonstrate a common goal in emphasizing the importance of investing in units of solution logic that are agnostic to business processes and applications and therefore highly reusable. It further promotes role-based development, allowing developers with different areas of expertise to collaborate.