Service-oriented computing represents a new generation distributed computing platform. As such, it encompasses many things, including its own design paradigm and design principles, design pattern catalogs, pattern languages, a distinct architectural model, and related concepts, technologies, and frameworks.
It sounds like a pretty big umbrella, and it is. Service-oriented computing builds upon past distributed computing platforms and adds new design layers, governance considerations, and a vast set of preferred implementation technologies. That’s why taking the time to understand its underlying mechanics before proceeding to the actual design and construction phases of a delivery project is time well spent.
To better understand the fundamental complexion of a typical service-oriented computing platform we need to describe each of its primary parts, which we’ll refer to as elements:
– Service-Oriented Architecture
– Service-Oriented Solution Logic
– Service Compositions
– Service Inventory
The following pages define each of these elements and conclude with illustrations that explain how they can inter-relate. The symbols introduced in the upcoming pages are used repeatedly within subsequent parts of this Web site, as well as the www.soaprinciples.com site, and the books in the Prentice Hall Service-Oriented Computing Series from Thomas Erl.
Service-Oriented Architecture (SOA)
SOA establishes an architectural model that aims to enhance the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of the strategic goals associated with service-oriented computing.
On a fundamental basis, the service-oriented computing platform revolves around the service-orientation design paradigm and its relationship with service-oriented architecture. In fact, the term “service-oriented architecture” and its associated acronym have been used so broadly by the media and within vendor marketing literature that it has almost become synonymous with service-oriented computing itself. It is therefore very important to make a clear distinction between what SOA actually is and how it relates to other service-oriented computing elements.
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 face 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.
Figure: Container symbols are used to represent architectural implementation environments.
Services and Service-Orientation
Service-orientation is a design paradigm comprised of a specific set of design principles. The application of these principles to the design of solution logic results in service-oriented solution logic. The most fundamental unit of service-oriented solution logic is the service.
Services exist as physically independent software programs with specific design characteristics that support the attainment of the strategic goals associated with service-oriented computing. The following figure introduces the symbols used by this site and the book series to represent a service from an endpoint perspective.
Figure: The yellow sphere symbol (left) is used to represent a whole service and the chorded circle symbol (right) is used to express a service and its capabilities.
Each service is assigned its own distinct functional context and is comprised of a set of capabilities related to this context. Those capabilities suitable for invocation by external consumer programs are commonly expressed via a published service contract (much like a traditional API).
Figure: The individual description documents that can comprise a service contract for a Web service.
A service composition is a coordinated aggregate of services. As explained on the Effects of Service-Orientation on the Enterprise page, a composition of services is comparable to a traditional application in that its functional scope is usually associated with the automation of a parent business process.
The consistent application of service-orientation design principles leads to the creation of services with functional contexts that are agnostic to any one business process. These agnostic services are therefore capable of participating in multiple service compositions.
As further discussed at www.soaprinciples.com, the ability for a service to be naturally and repeatedly composable is fundamental to attaining several of the strategic goals of service-oriented computing. Therefore, many of the design characteristics that distinguish a service enable it to effectively participate in service compositions.
Figure: The symbol comprised of three connected spheres represents a service composition. Other, more detailed representations are based on the use of chorded circle symbols (below) to specifically identify which service capabilities are actually being composed.
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.
Figure: The service inventory symbol consists of yellow spheres within a blue container.
An IT enterprise may include a service inventory that represents the extent to which SOA has been adopted. Larger initiatives may even result in the enterprise in its entirety being comprised of an enterprise-wide service inventory. Alternatively, an enterprise environment can contain multiple service inventories, each of which can be individually standardized, governed, and supported by its own service-oriented technology architecture.
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.
Figure: The service inventory grows as projects deliver new services. Plus, opportunities to reuse existing services increase with each subsequent project.