Design Principles and Structure of Orchestration-Driven Service-Oriented Architecture

Key Insight

Orchestration-Driven Service-Oriented Architecture (SOA) emerged in the late 1990s, coinciding with companies' rapid expansion into enterprises through mergers, demanding more sophisticated IT. This era was characterized by scarce and expensive computing resources, with operating systems and commercial database servers licensed per machine, which propelled the need for distributed computing and aggressive reuse. The architecture's driving philosophy aimed to eliminate the continuous rewriting of software by promoting maximum technical partitioning and component reuse, leading to conflicts between application server vendors offering features like database connection pooling and database vendors.

The architecture's structure employs a taxonomy of services, each with distinct responsibilities, designed to achieve enterprise-level reuse. Business Services, at the top, serve as entry points representing domain behavior, such as 'ExecuteTrade' or 'PlaceOrder', typically defined by business users without containing actual code. Enterprise Services provide fine-grained, shared, and atomic implementations like 'CreateCustomer' or 'CalculateQuote'; these are the building blocks for Business Services and are intended to be reusable assets. Application Services are one-off, single-implementation solutions for specific application needs, such as geo-location, without requiring broader organizational reuse. Infrastructure Services address operational concerns including monitoring, logging, authentication, and authorization, and are typically managed by a shared infrastructure team.

Central to this distributed architecture is the Orchestration Engine, which orchestrates and stitches together Business Service implementations, incorporating features like transactional coordination and message transformation. This engine defines the relationships between business and enterprise services, mapping them and establishing transaction boundaries, while also serving as an integration hub for custom code, package, and legacy systems. Unlike microservices, this SOA style generally relies on a single or a few relational databases, with transactional behavior handled declaratively by the orchestration engine. All message flow within the architecture passes through this engine, which houses the system's logic; for example, a 'CreateQuote' business service would call the service bus, which then orchestrates calls to services like 'CreateCustomer' and 'CalculateQuote'.