1: SOA Primer
The author uses electricity as an example of a service: within a person's home, electricity is available to power various devices, which a person uses as-needed to fulfill specific needs, seldom giving a thought to the electric power on which these devices and tasks depend. It's simply there, in a supporting role, and the user doesn't consider the infrastructure necessary to deliver it.
The author continues with this metaphor: the usage of electricity, while invisible, is ubiquitous, and it is so by design. Edison might well have developed an array of devices, each of which was entirely self-contained, with a power generator built into every device. But instead, the model was to create an external service that made it unnecessary for each device to have these redundant power-generating capabilities.
From a systemic perspective, this gives the industry that generates electricity to do so in a manner that makes it cheaply available to all users: a central facility producing power enjoys considerable economies of scale, and it's possible to manage the power supply to a large number of users to grow or adjust capacity based on usage.
(EN: To pick on the metaphor, it's worth noting that many devices do have a self-contained source of power, in the form of batteries. And it's notable that "battery power" is necessary to any device that is considered critical when the power service fails - flashlights, emergency radios, backup power for computer systems, etc.)
The author then parallels this to current practices in software development. Each IT solution attempts to be self-contained and comprehensive, such that the same data and functionality may be resident in a dozen different systems. This level of redundancy is highly wasteful and inefficient and can lead to inconsistent information and practices within an enterprise.
A better solution is to design data services that can be shared or leveraged by multiple systems within a company. In some contexts, it may even be possible for a single source to provide a service that can be leveraged by different companies. For example, it doesn't make sense for every company to create and maintain a database of ZIP codes when a single neutral source (such as the US Postal Service) can provide this as a service to them. This is the model used for most business operations - using the same example, the vast majority of companies do not maintain a fleet of delivery vehicles, but use third-party shippers.
WHAT EXACTLY IS SOA?
In simple terms, SOA can be defined as establishing "enterprise" capabilities that can be leveraged for IT solutions.
The requirements to create a service, and the technical details of the solution, can vary widely, and the path from the current environment of monolithic systems that propose to do everything to a system in which many small, lightweight services are coordinated to perform complex tasks, makes it a much more convoluted topic than the basic definition would imply.
To illustrate the basic concept, the author provides a diagram of four "layers" of information systems:
- Operational Resources - Includes the existing systems, applications, databases, and other elements that comprise the legacy enterprise
- Enterprise Components - A middle layer of "container-based technologies" that extracts and organizes information and functions out of the various systems, generally for the purpose of making data contained within "black box" solutions accessible to other systems.
- Services - Another layer that exploits the enterprise components to isolate molecules of data or very specific functions.
- Business Processes - A layer that bundles together myriad services and orchestrates their execution order to provide a solution to a business problem.
(EN: Seems to me that this goes full circle. The enterprise resources are smashed into molecules, then those molecules are reassembled, which may end up doing the same tasks as the original enterprise resources. At first blush, it seems pointless, but the SOA model would have the advantage of being able to eliminate redundant molecules and combine them in new ways, more nimbly than a new black-box system would be able to do).
IS SOA A FAD?
Given the level of hype in internet technology, one must question whether the attention given to any new technology is warranted. With SOA, there are a few factors that support the position that it will have longevity:
The emergence of the Web required businesses to change their enterprise architecture to provide access to data and functionality of black-box systems and provide more nimble and adaptable capabilities. Likewise, the perceived need to integrate information systems has required the establishment of small, purpose-built middleware components that enable systems to communicate with one another and share, rather than duplicate, services.
With this in mind, SOA is an established practice that serves a legitimate need, merely given a name and approached in a more methodical and orchestrated manner, which is the hallmark of a lasting change rather than a passing fancy.
CASE STUDY
(EN: The author ends each chapter with a "case study" to illustrate concepts - but I'm skipping them. Aside of providing no new information, each seems like a hypothetical example where the results achieved by SAO are so fantastical as to seem entirely fabricated and contrived.)