System Design: Orchestration-Driven Service-Oriented Architecture

The orchestration-driven service-oriented architecture was a popular software architecture style in the late 1990s, and is less popular today. However, understanding its strengths and weaknesses is helpful in establishing a holistic understanding of modern software architecture.

Architecture Components

This architecture’s main design philosophy is to maximize code reuse. The entire system consists of multiple layers, and each layer has a set of distributed services, but the exact layers in each application are different, and the boundaries are not always clear. Below are some of the most common layers in this architecture style.

Business Services

The business services layer usually sit at the top of the entire system, and acts as the entry point to the application. Each service within this layer represents a specific business task, such as executing a trade and placing an order.

Enterprise Services

The enterprise services layer contains a set of shared implementations that are used by various business services. These services are the atomic building blocks that make up each business service, and they are tied together by an orchestration engine. This layer demonstrates the overarching goal of this architecture style to maximize code reuse.

Application Services

Some implementations could not be reused, as they are one-off implementations of very specific tasks. These implementations are placed within the application services layer, which contains a set of non-reusable services.

Infrastructure Services

The infrastructure services layer contains the services that support the entire system on an operational level. These services include monitoring, logging, authentication, and authorization.

Orchestration Engine

The orchestration engine is the core component of the orchestration-driven service-oriented architecture, as the name suggests. It coordinates the communication between the business services and the implementation services. It also acts as an integration hub to integrate the implementation services into code packages that can be used by the business services.

This architecture typically uses a single database, and that database is tied to the orchestration engine rather than called directly by each of the individual services. This means that the orchestration engine coordinates all transactions and relays all messages. All requests must go through the orchestration engine, even internal requests.

Trade-Offs

Advantages

• This architecture style is relatively scalable and elastic because of its distributed nature.

Disadvantages

• The orchestration engine becomes a coupling point for the entire system and is not only a single point of failure, but is also very difficult to make incremental changes.
• Deployability and testability are very low, because different services are closely coupled in the attempt to maximize code reuse.
• This architecture style is complex and expensive to maintain.