What the orchestrated service-oriented architecture can do
In the world of software architecture, there are various models that target different requirements and objectives. One such model is the orchestrated service-oriented architecture model, which provides for a clear separation of business logic and services. In this blog post, we take a closer look at this architecture model, its components and discuss advantages and disadvantages.
The entry layer of this architecture consists of business services that are subdivided on a domain-specific basis. These business services are made up of simplified methods, known as enterprise services. The separation of these services is aimed at reusability. Several business services can use the same enterprise services. In addition, there are uniquely implemented application services and infrastructure services that are responsible for logging, monitoring, authentication and authorization. The orchestration engine acts as a link between the business services and the enterprise services and determines the relationship between business logic and enterprise services.
Although the idea of reusability seems attractive in theory, it can lead to difficulties in practice. A change to an enterprise service, such as "createCustomer()", can have an impact on other business services that also require this function. This leads to a strong coupling and makes efficient development processes more difficult compared to microservices, for example.
It is important to note that the business service architecture model is not widely used today and is no longer used in most modern software applications. This is partly because testability and deployability were not primary goals at the time this style was developed. However, there are certain use cases where this model may still be relevant, especially in legacy systems or specific domains where reusability of services is critical.
One advantage of this architecture model is its scalability through session replication. This means that large load peaks can be managed. However, the model also has some disadvantages. Testability and deployability are often poor, as these aspects were not a priority during development. In addition, the orchestration engine can become a bottleneck as a central connection point.
Conclusion
The business service architecture model offers an interesting perspective on the separation of business logic and services. Although it has some advantages such as scalability, the challenges and problems of implementation should be considered. Nowadays, many developers prefer other architectural styles such as microservices, which are more flexible and scalable. However, the business service architecture model may still have its place in certain legacy systems or specific domains. The decision for the right architecture model ultimately depends on the individual requirements and objectives of the project.
Summary
We have briefly summarized the most important features of this style for you as a picture.
Disclaimer: The Architecture Spicker is largely based on the book Handbook of modern software architecture by O'Reilly. For more in-depth information, we recommend buying this book.
