Application Architectures - The Practice of Cloud System Administration - page 90

4.7 Service-Oriented Architecture
Service-oriented architecture (SOA) enables large services to be managed more easily.
Withthisarchitecture,eachsubsystemisaself-containedserviceprovidingitsfunctionality
as a consumable service via an API. The various services communicate with one another
by making API calls.
A goal of SOAs is to have the services be loosely coupled. That is, each API presents
its service at a high level of abstraction. This makes it easier to improve and even replace a
service. The replacement must simply provide the same abstraction. Loosely coupled sys-
tems do not know the internal workings of the other systems that are part of the architec-
ture. If they did, they would be tightly bound to each other.
As an example, imagine a job scheduler service. It accepts requests to perform various
actions, schedules them, coordinates them, and reports back progress as it executes. In a
tightly coupled system, the API would be tightly linked to the inner workings of the job
scheduler. Users of the API could specify details related to how the jobs work rather than
what is needed. For example, the API might provide direct access to the status of the lock
mechanism used to prevent the same job from being executed twice.
Suppose a new internal design was proposed that prevented duplicate job execution but
did locking some other way. This change could not be made without changing the code of
all the services that used the API. In a loosely coupled system, the API would provide job
status at a higher level of abstraction: is the job waiting, is it running, where is it running,
can it be stopped, and so on. No matter what the internal implementation was, these re-
quests could be processed.
4.7.1 Flexibility
AnSOAmakesiteasierforservicestocooperate.Servicescanbecombinedinmany,often
unexpected, ways to create new applications. New applications can be designed without
consultation of all the other services as long as the API meets the new application's needs.
Each subsystem can be managed as a discrete system. It is easier to manage a few, small,
easy-to-understand services than one large system with ill-defined internal interconnec-
tions. When the touch-points between services are well-defined APIs that implement high-
level abstractions, it makes it easier to evolve and/or replace the service.