Service-Oriented Computing Fundamentals

Service-Oriented Computing
Service-oriented computing is an umbrella term that represents a new generation distributed computing platform. As such, it encompasses many things, including its own design paradigm and design principles, design patterns, a distinct architectural model, and related concepts, technologies, and frameworks. Service-oriented computing builds upon past distributed computing platforms and adds new design layers, governance considerations, and a vast set of preferred implementation technologies, several of which are based on the Web services framework.
In this book we make reference to the strategic goals of service-oriented computing as they relate to the application of service-orientation and the design of service-oriented architecture.

Service-Orientation
Service-orientation is a design paradigm intended for the creation of solution logic units that are individually shaped so that they can be collectively and repeatedly utilized in support of the realization of the specific strategic goals and benefits associated with SOA and serviceoriented 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, in fact, has many roots in object-orientation and has also been influenced by other industry developments, as shown in Figure

Service-Oriented Architecture (SOA)
Service-oriented architecture represents an architectural model that aims to enhance the agility and cost-effectiveness of an enterprise while reducing the burden of IT on the overall organization. It accomplishes this by positioning services as the primary means through which solution logic is represented. SOA supports service-orientation in the realization of the strategic goals associated with service-oriented computing. 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. 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; however it is 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 around the service-oriented architectural model establishes an environment suitable for solution logic that has been designed in compliance with service-orientation design principles.

Service
A service is a unit of solution logic (Figure) to which serviceorientation 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 or components. 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.

Service Capability
Each service is assigned its own distinct functional context and is comprised of a set of functions or capabilities related to this context. Therefore, a service can be considered a container of capabilities associated with a common purpose (based on a common functional context). The individual bullet items within the service symbol from above Figure are capabilities.

The term service capability has no implication as to how a service is implemented. Therefore, this term can be specially useful during service modeling stages when the physical design of a service has not yet been determined (at which point it is further qualified as a service capability candidate).

Service Consumer
When a program invokes and interacts with a service it is labeled as a service consumer. It is very important to understand that this term refers to the temporary runtime role assumed by a program when it is engaging a service in a data exchange.
For example, you can create a desktop application that is capable of exchanging messages with a service. When it is interacting with the service, the desktop application is considered a service consumer.
You can also design a service to invoke and interact with other services (which, in fact, forms the basis of a service composition, as explained in the next section). In this case, the service itself will temporarily act as the service consumer (below Figure). Many of the examples in the upcoming chapters show consumers as services. Furthermore, due to the unpredictable nature of data flow through service compositions, the directionality between consumers and services is intentionally not standardized in diagrams provided in this book (which is a deviation from the left-to-right convention used with traditional client-server illustrations).