Architecture styles make sense to architects in the context of the era when they evolved, but lose relevance in later eras, much like art movements. Orchestration-driven service-oriented architecture (SOA) exemplifies this tendency. The external forces that often influence architecture decisions, combined with a logical but ultimately disastrous organizational philosophy, doomed this architecture to irrelevance. However, it provides a great example of how a particular organizational idea can make logical sense yet hinder the most important parts of the development process. It illustrates one of the dangers of ignoring our First Law: everything in software architecture is a trade-off.
Topology
The topology of orchestration-driven SOA is shown in Figure 17-1.
Not all examples of this style of architecture have these exact layers, but they all follow the same idea of establishing a taxonomy of services within the architecture, each layer with a specific, well-defined responsibility.
Service-oriented architecture is a distributed architecture. The exact demarcation of boundaries isn’t shown in Figure 17-1 because it varies based on organization and tools: some of the parts of the taxonomy may exist inside an application server. Orchestration-driven SOA centers on a specific taxonomy of services, with different technical responsibilities within the architecture and roles dedicated to specific layers.
Figure 17-1. Topology ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month, and much more.
