The Complete Guide to SOA, MSA and Modulith
- 박준성 박사: Univ. of Iowa 종신교수, 삼성SDS CTO, KAIST 초빙교수
- Dec 6, 2025
- 48 min read
Updated: Dec 7, 2025
Service-Oriented Architecture (SOA) is an architecture style in which an application is composed of loosely coupled services that communicate with each other through standardized interfaces such as APIs or event-based messaging mechanisms.
SOA design and implementation patterns have continuously evolved since the early 2000s: from SOAP-based to HTTP-based services, from coarse-grained to fine-grained services, from monolithic to distributed deployment, from a shared database to distributed databases, from business process-based orchestration to event-driven choreography, etc.
Microservice Architecture (MSA) gained traction from the early 2010s. It was a particular style of SOA for DevOps where each DevOps team owns dozens of services and deploys each service independently. From the early 2020s MSA lost traction and is being replaced by Modular Monolith (Modulith) architecture, a new name for conventional SOA with monolithic deployment.
Design and implementation patterns changed over time reflecting changes in business objectives for SOA and changes in technologies supporting SOA. However, design principles, analysis and design methodologies, and a majority of design patterns remain effective across different types of SOA we have seen over the last thirty years.
Today most companies are interested in developing AI agents. The AI agent system is also SOA. It is important to understand and be capable of applying SOA design principles, design patterns, and analysis and design methodologies to be successful in developing AI agent systems that contribute to improving business performance.
Table of Content
History of SOA
Definition of SOA, MSA and Modulith
MSA Benefits and Drawbacks
MSA Adoption Strategy
SOA Benefits
SOA Principles
SOA Service Design Patterns
SOA Service Composition Patterns
SOA Service Inventory Patterns
SOA Analysis & Design Methodologies
History of SOA
Gartner first coined the term SOA in 1996 as a software architecture that starts with an interface definition and builds the entire application topology as a topology of interfaces, interface implementations and interface calls. (W. Schulte and N. V. Yefim , Service Oriented Architecture, Part 1, Gartner report SPA-401–068, 12 April 1996)
Worldwide adoption of SOA started since early 2000s when W3C adopted the Web Services (with its components SOAP, WSDL and UDDI) as the standardized, network-accessible services that allow applications to communicate in a platform-independent, language-independent way. With this global standard API technology at hand, firms could now develop an application as a composition of loosely coupled modules (i.e., services) which can be developed using different languages and platforms.
Early SOA applications in the 2000s were implemented using SOAP, WSDL, enterprise service bus (ESB), Business Process Management (BPM)-based orchestration, and commercial web application servers (WAS) such as IBM WebSphere, Oracle WebLogic, and Microsoft .NET. An entire SOA application used a shared database, and was deployed monolithically, to minimize the costs of DBMS and WAS licenses for one thing.
During the 2000s, SOA design principles, patterns and methodologies got matured, and most commercial software product was redesigned into SOA, and most professional IT service provider and most IT-savvy enterprise start building their information systems in SOA. For example, SAP decomposed its ERP product into seven thousand SOA services in 2004 and provided the NetWeaver application server which can be used to orchestrate the services into a business process. IBM incorporated SOA into the Rational Unified Process (RUP) in 2007, which was the standard application development process for global leading IT service providers like Accenture and Capgemini. AUTOSAR (AUTomotive Open System ARchitecture), a standardized software architecture for automotive electronic control units (ECUs), adopted SOA in 2011. As can be seen in Figure 1, 90% of European firms surveyed by Gartner had already implemented SOA in 2008 or planned to do it in the next year.
By the late 2000s, the Representational State Transfer (REST) gradually replaced SOAP-based Web Services as it is lighter, simpler, and easier to consume, and became the de facto standard for public APIs, with JSON replacing XML as the preferred payload format. The early SOA implementation technologies such as ESB, BPM and WAS were also replaced by lighter, simpler, and cheaper (or free, open source) platforms.
From the 2010s we have built and used both SOAP-based SOA and REST-based SOA. Several architecture styles were proposed for REST-based SOA prior to the advent of MSA: Resource-Oriented Architecture (ROA) promoted by L. Richardson from 2002 as a SOA with RESTful services; Web-Oriented Architecture (WOA) coined by N. Gall of Gartner in 2006 as SOA + WWW + REST; and SOA 2.0 promoted by Oracle in 2006 as Event-Driven SOA.
ThoughtWorks popularized the term MSA in 2014 as a particular way of designing software applications as suites of independently deployable services. (https://martinfowler.com/articles/microservices.html) MSA is a REST-based SOA where each RESTful service with its own dedicated physical database is deployed independently, and uses event-driven mechanisms such as choreography for service composition and event sourcing in place of a database. As DBMSs such as MySQL and PostgreSQL and application frameworks such as Spring and Express were provided as open source, firms could use them free for per-service database and per-service deployment. Since the late 2010s, GraphQL and gRPC were increasingly used in place of REST. Since REST, GraphQL and gRPC are all HTTP based, we can now classify SOA into two categories: SOAP-based SOA and HTTP-based SOA.
Lastly, Modulith Architecture, which means a single deployable unit (monolith) whose internal structure is modular (service-oriented), became an architecture style supported by the Spring Framework team in 2022 with the Spring Modulith project. The Modulith turns away from MSA towards the previous HTTP-based SOA where the entire application, rather than individual services, is the unit of deployment.
There were a couple of HTTP-based SOA proposed that are positioned somewhere between MSA and Modulith: Service-Based Architecture proposed by ThoughtWorks (M. Richards and N. Ford, Fundamentals of Software Architecture: An Engineering Approach, 2020), and Miniservice Architecture proposed by Gartner. (A. Thomas, When Should You Use Microservices, Gartner, 2021.) Both the Service-Based Architecture and Miniservice Architecture proposed to make more coarse-grained, smaller number of services than MSA (like 4–12 services per application) and to share a database rather than giving a separate database for each service.
Definition of SOA, MSA and Modulith
In this article, we will use the term SOA to mean a broad category of architecture styles in which application functionality is organized into loosely coupled services that communicate via standardized interfaces and protocols across a network. The term SOA will encompass the original SOAP-based SOA, and all HTTP-based SOA including MSA and Modulith.
There is no formal definition of microservice. Microservice is a collection of emerging patterns of SOA that have been proven effective in several web scale companies including Amazon, Netflix, Gilt, REA Group, Google, eBay, Twitter, LinkedIn, SoundCloud, Uber, Airbnb, Hailo, etc. Microservice emerged out of the business needs of those companies to stay at the top of competition in their respective markets.
See what other people said about microservices. Adrian Cockcroft, VP of Cloud Architecture Strategy at Amazon, described microservices as loosely coupled service-oriented architecture with bounded context. Here bounded context is a term defined by Eric Evans in his book on Domain-Driven Design. It means an explicitly defined context for each service within which a domain model expressing a ubiquitous language exists.
James Lewis, Principal Consultant at ThoughtWorks, expressed his view on microservices as developing an application as a suite of small services, each running in its own process and communicating with lightweight … API. … built around business capabilities and independently deployable by fully automated deployment machinery.
Lastly, Modulith is, as defined above, HTTP-based SOA where the entire application is the unit of deployment. Modulith is similar to the original SOAP-based SOA except that it uses HTTP-based API protocols and modern open-source platforms.
Table 1 clarifies the differences and similarities among SOA, MSA and Modulith. The second column titled 2005 SOA shows the properties of SOAP-based SOA. The third column titled 2015 MSA shows the properties of MSA. The rows colored in yellow are the properties of Modulith.
Modulith today abandoned old technologies such as SOAP Web Services, commercial web application server (WAS), on-premises virtual machine (VM), and enterprise service bus (ESB) used by SOAP-based SOA. It adopted modern technologies such as REST (and GraphQL and gRPC), open-source application frameworks (such as Spring Boot, Spring Cloud, Express, and FastAPI), containers in the cloud, event bus (like Apache Kafka), API gateway, and event-driven choreography. It also inherited the following properties of conventional SOAP-based SOA: BPM orchestration, shared database, monolithic UI, and monolithic deployment. On the other hand, it abandoned following MSA patterns that are too disruptive and complex for ordinary enterprises: event sourcing database, database per service, microfrontend, deployment of individual services, and DevOps teams.
With clear definitions of SOA, MSA and Modulith, we can now move to detailed discussions on characteristics, benefits, drawbacks, design principles, and design patterns of each. Recall that SOA is a comprehensive term that encompasses both SOAP-based and HTTP-based SOA, and that HTTP-based SOA includes both MSA and Modulith.
MSA Benefits and Drawbacks
Understanding the business needs for microservices of the above listed web scale companies which have pioneered microservices will clarify why microservice came about and what it tries to achieve. The companies listed above have common characteristics and common business needs. They are the most advanced digital companies in the world. Their businesses are software-intensive, deliver web-based services on a global scale, run entirely on the cloud, and are continually innovated setting examples for other companies in their respective industries. What their businesses need in common is to change their business models and processes fast enough to fend off imitators, and to change their applications fast enough to deliver incremental values to customers frequently.
What they had as impediments in their way was monolithic applications hard and slow to change. Their applications were already layered, modular and service-oriented, but packaged and deployed as a monolith. As a result, application is too large and complex to fully understand and make changes fast and correctly; the sheer size of application can slow down the start-up time; they must redeploy the entire application on each update; impact of a change is usually not very well understood which leads to extensive manual testing; application can be difficult to scale when different modules have conflicting resource requirements; bug in any module can bring down the entire process; it is difficult and extremely expensive to adopt new technologies since changes in frameworks or languages will affect an entire application. (https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59)
To move faster they had to devise a way to make changes simpler. The solution was what are now regarded microservice architecture (MSA) patterns. They divided the monolith into hundreds of small services; made these services as independent as possible; minimized inter-service dependencies by having each service physically contain and exclusively access its own database; and had a single team of small size with deep knowledge of the bounded context both develop and operate each service.
The benefits of MSA include: it tackles the problem of complexity by decomposing application into a set of manageable services which are much faster to develop, and much easier to understand and maintain; it enables each service to be developed independently by a team that is focused on that service; it reduces barrier of adopting new technologies since the developers are free to choose whatever technologies making sense for their service and not bounded to the choices made at the start of the project; it enables each service to be deployed independently, thus making continuous deployment (CD) possible for complex applications; it enables each service to be scaled independently.
Netflix, a company serving movies and TV shows to more than seventy five million global subscribers, began converting its monolithic, datacenter-based Java application to cloud-based Java microservices and migrated those services to AWS in 2008. (https://medium.com/netflix-techblog/how-we-build-code-at-netflix-c5d9bd727f15) Netflix’ software engineering went from a few teams checking code into a large monolithic application running on tens of servers to having tens of engineering teams developing hundreds of component services that run on thousands of servers. Figure 2 shows hundreds of fine-grained services in Netflix that communicate with each other using a light-weight REST based protocol. (G. Oliffe, You Are Not Netflix: How and When to Use Microservices in the Enterprise, Gartner Catalyst Conference, 2016.)
However, there are serious drawbacks of MSA if your company is not ready with the skills, methods, tools, frameworks, platforms and infrastructure required to build and operate MSA applications properly: MSA is essentially an extremely distributed computing system which requires a complex web of inter-process communication based on either messaging or RPC; it requires writing code to handle partial failures and other fallacies of distributed computing; it has the partitioned database architecture with each service physically containing its own database, and therefore, transaction management to preserve ACID properties is more challenging; it is more complex to test services because they typically depend on many other services; it requires each instance of each service to be configured, deployed, scaled and monitored, and this level of complexity requires a high level of automation.
Martin Fowler advised that if you do not have certain baseline competencies, you shouldn’t consider using the microservice style. He listed rapid provisioning, basic monitoring, rapid application deployment, and DevOps culture as required competencies. (https://martinfowler.com/bliki/MicroservicePrerequisites.html)
MSA Adoption Strategy
The decision of whether to adopt microservice architecture (MSA) in an enterprise is not an all-or-nothing proposition. Depending on the nature of business, the maturity level of IT, the competency level of software engineers, all the MSA patterns found in the pioneering companies may not be necessary or feasible.
To select appropriate MSA patterns to adopt in an enterprise, the company should think about the business goals to achieve and/or the urgent business or IT problems to solve by adopting MSA. Business drivers for adopting MSA of early adopters have been the following:
Fast Release Cycle: Pushing each feature in one cycle of the service deployment using IaaS+PaaS and DevOps automation.
Global Scalability: Automated scaling of individual services based on IaaS+PaaS.
Technological Diversity: Allowing different languages, development frameworks, data storage technologies, infrastructure types for different services within an application.
Large Development Organization with Small Independent Teams: Many small autonomous teams (1~10) comprised of fully empowered, competent developers independently producing microservices.
In some companies, application users or product customers do not need or want fast upgrades. Not many companies need extreme agility, global-scale scalability and technology diversity that drove the MSA patterns found in those pioneering companies. If your company does not really have any of the above drivers, you should step back and now think about the benefits of Modulith.
MSA evolved as a fresh style of SOA exploiting new advances in computing technologies such as IaaS, PaaS, containers, container management tools, CI/CD automation tools, API gateways, and backing services such as persistent services and messaging services, and telemetry including monitoring, logging, etc. Even if your company cannot use all these recent technologies enabling the MSA patterns, you can still pursue benefits of Modulith by selecting the Modulith patterns and some of the MSA patterns that fit your business purpose and can be handled with your current IT capabilities.
In fact, Gartner predicted that by 2019, more than 90% of organizations that investigate MSA will find the paradigm too disruptive and adopt miniservices instead. Here miniservices mean SOA services that have relaxed architectural constraints than state-of-art microservices; for example, increasing the granularity of services, thereby reducing the number of services, sharing a database among services instead of each service physically owning a separate database; using RPC or orchestration instead of choreography based on the publish-and-subscribe messaging. (Gartner, Innovation Insight for Miniservices, 2017.) Miniservice Architecture is similar to Modulith Architecture except that it allows independent deployment of individual services.
SOA, including SOAP-based SOA, MSA, Modulith, and their hybrids, is the foundation of modern application architecture. Understanding principles, benefits, design patterns, and engineering methods of SOA in general are all essential to understanding and implementing MSA correctly. Refer to: Gartner, Where to Start (or Restart) with Service-Oriented Architecture, 2016.
If your company aspire any of the SOA benefits discussed below, but has not institutionalized SOA yet, you should start the journey of adopting SOA. You may adopt MSA patterns selectively along the way, but you will have less risk if you try MSA after you have built a solid foundation in SOA.
The strangler pattern is a widely advocated strategy for adopting MSA. It starts with a Modulith, and incrementally transforms a Modulith into microservices by replacing a particular functionality by a new microservice if per-service deployment is wanted for that functionality. (https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html)
SOA Benefits
The benefits of (i.e., drivers for, goals of, or values of) SOA, which are also benefits of MSA and Modulith, include the following:
Business-IT Alignment
SOA services are designed to encapsulate business process activities and the information used by the activities so that the business model is faithfully represented by the collection of services. New business requirements can be addressed by establishing a service layer capturing the new business model and wrapping useful functionalities in legacy applications, with the effect of increasing the speed and reducing the cost of new application development.
Business analysts should identify business services during the business requirements analysis phase of application development, which are detailed and implemented as SOA services in later phases. Enterprise architects can define SOA services from business viewpoint as early as when designing the enterprise architecture (EA). Each service should encapsulate closely related business processes and business objects defined in the EA. Business analysts should specify the business processes that dynamically orchestrate or choreograph the SOA services. Explicit business process models facilitate in-flight process reengineering in response to fast changing business environments. Refer to: The Complete Guide to Business Analysis (https://www.kosta-online.com/post/the-complete-guide-to-business-analysis) for more details.
Figure 3 shows an SOA where services are composed dynamically using process orchestration.
Service-Oriented Enterprise Architecture
SOA services are united while maintaining their individual autonomy. Business capabilities are expressed by service APIs in a standardized manner so that they can be easily composed into various applications across the enterprise. J. Ross, et al. showed, based on a survey of more than two hundred companies, that companies that were most mature in enterprise architecture (EA) had achieved componentization of business capabilities with standard interfaces for business modularity (J. Ross, et al., Enterprise Architecture as Strategy, Harvard Business Review Press, 2006.) SOA has become a de facto standard for EA among global companies by around late 2000s.
Figure 4 shows the metamodel for service-oriented enterprise architecture recommended in TOGAF. Refer to: The Open Group, Using TOGAF for Enterprise SOA (http://www.opengroup.org/soa/source-book/togaf/p4.htm). SOA is an essential competency for business analysts (BAs) as well as enterprise architects (EAs) today. Capgemini, for example, required SOA as an essential competency in its BA certification since late 2000s.
Universal Interoperability
SOA services are natively interoperable using APIs for inter-service communication. Applications in SOA can be easily integrated via APIs, with the effect of far reducing the efforts and costs required for application-to-application (A2A) integration as well as business-to-business (B2B) integration. Using standard API technologies such as SOAP and REST web services, any piece of software wrapped in published API can be called by any other software through the Internet. While the Internet enabled a computer to be connected to any other computer in the world if it has an IP address, the Internet-based web services enabled a piece of software to be connected to any other software in the world if it has a published API using standard protocols.
Cloud services are SOA services using standard SOAP or REST web services. Amazon, which pioneered IaaS and branded it as Amazon Web Services (AWS), adopted SOA enterprise-wide in 2002, published web service API of its product data to third-party affiliates — Web sites that advertised Amazon products using the Amazon’s API and received a portion of Amazon’s resulting sales — in the same year, and expanded the web services to sell its storage, computing and other technology services to software developers the next year 2003. Digital businesses connect things (i.e., Internet of Things or IoT), people and businesses together, and they are all connected via API. Even endpoint devices expose REST API. A quote on this point by Sam Macklin of CA Technology: In the future, every successful company will be a software company and every successful software company will be an API provider.
Implementation Independence
Service APIs are decoupled from the service implementation so that implementation technologies can be changed without disrupting the federated application architecture, with the effect of prolonging the lifespan and ROI of investments in applications. A SOA service encapsulates business use cases and business object classes that have a high degree of affinity. This allows us to describe service APIs in business terminologies in an implementation agnostic way.
Asset with Long-Term ROI
Services encapsulating common functionalities and data can be reused across different applications saving time and cost. Reusable SOA services are an important asset in any enterprise that can generate recurring returns over a long term.
Enterprises with a service inventory comprised of more reusable SOA services take less effort and time to change business processes and applications.
It should be noted, however, that MSA discourages service reusability to make them as independent as possible. MSA sacrifices reusability in favor of extreme business agility realized by fast per-service release cycles. Amazon, for example, releases updated services multiple times a second.
SOA Principles
Kent Beck suggests a useful distinction between values, principles, and practices in software engineering (K. Beck, Extreme Programming Explained, 2nd ed., 2005). Practices are things you do repeatedly — such as a clustering analysis on an affinity matrix to generate a first-cut design of business services (discussed in The Complete Guide to Business Analysis (https://www.kosta-online.com/post/the-complete-guide-to-business-analysis)). Values are purposes of practices. The above listed drivers (i.e., goals, benefits) of SOA and MSA are values sought after by enterprises when investing in SOA and MSA, respectively.
If your company does not place a high value on extreme business agility with multiple times of update deployment a day, it may not choose certain MSA patterns such as the continuous, independent deployment of individual services. Practices should be chosen based on the value your company thinks are important. The values pursued by different companies can be different.
Principles are guidelines that bridge the gap between values and practices. For example, the Standardized Service Contract principle discussed below leads you to the practice of adopting standard protocols such as SOAP or REST web services across your enterprise, so that the Universal Interoperability value can be realized.
SOA principles are discussed next. These principles apply to SOA in general including MSA and Modulith unless otherwise noted.
A SOA service is a composition of closely related objects in object-oriented programming (OOP). As proposed in Domain -Driven Design (DDD) (Eric Evans, Domain-Driven Design, 2003), a bounded context in a domain model is a suitable candidate for a service in that domain. The domain model shows all the classes comprising the object-oriented program for the domain. The bonded context is a subset of those classes that share a ubiquitous language, i.e., a shard vocabulary or a shared set of terms and concepts.
SOA services and OOP objects share the following basic properties: Services and objects both expose their functionalities through interfaces and encapsulate functions (use cases and methods, respectively) and data (business objects and fields, respectively). Services, however, are different from objects in that there is no inheritance, no shared memory, no direct method calls among services.
Therefore, SOA principles share object design principles. Among the five object design principles known as SOLID (https://en.wikipedia.org/wiki/SOLID), the following four apply to SOA as well:
Single Responsibility Principle
Just like every class should have only one responsibility, so does every service. A service should represent a bounded context, i.e., a coherent and loosely coupled business capability.
Open–Closed Principle
Just like every class should be open for extension, but closed for modification, so does every service. We should never modify the API of a service, once published, but can extended the API adding more operations or add more APIs for the service.
If event-based messaging is used for communication among services in MSA, the event schema, once published, should never be modified, although it can be extended.
If this principle is violated, services can no longer rely on each other, nullifying the benefit of SOA. Therefore, a SOA governance is essential that enforces every developer in your organization honor this principle.
Interface Segregation Principle
Just like clients of a class should not be forced to depend upon interfaces that they do not need, so do clients of a service. A service should have a separate interface for a client, if necessary, to provide the minimal sufficient operations it needs.
When event-based messaging is used for communication among services in MSA, the event publishing service publishes a single, well-defined event schema. It is event consumers’ burden to transform the given schema to their needs.
Dependency Inversion Principle
Just like classes should depend only upon the interfaces of other classes, not their implementations, so do services. This principle allows changing the implementation of a service without affecting other services. It reduces dependencies between services, making the code easier to understand, modify and test, and thus more flexible.
This principle also applies when event-based messaging is used for communication among services in MSA. Event consuming services only need to know what event occurred and what data is in it, not how the event publisher generated or processed it.
Below are additional SOA principles that we adopted from Thomas Erl, SOA: Principles of Service Design, Prentice-Hall, 2007. (https://www.thomaserl.com/book/soa-principles-of-service-design/table-of-contents/index.html).
Standardized Service Contract
Services within the same service inventory should follow the same contract design standards. A service inventory is an independently standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise.
This principle is applied when designing a service’s public technical interface and determining the content to be published as part of a service’s official contract. REST uses uniform contract consisting of resource identifier (e.g., URI), media type (e.g., XML) and method (e.g., HTTP). SOAP web services use such standards as the WSDL definition of service metadata, XSD schema and WS-policy. Event-based messaging in MSA uses a community standard like CloudEvents for metadata and a schema definition language (JSON Schema, Avro, Protocol Buffers, etc.).
Service Loose Coupling
A service contract should impose low coupling to its service consumers, its implementation and surrounding environment. This principle promotes the independent design and evolution of a service’s logic and implementation while still guaranteeing baseline interoperability with consumers relying on the service’s capabilities.
Figure 5 shows various types of potential coupling that should be minimized: coupling between service consumer and service API, coupling between service API and service logic, coupling between service logic and service implementation, coupling between service logic and backing services such as shared databases, coupling between service logic and other services, coupling between business process and service API or logic. A handful of SOA design patterns to be discussed below are to attain loose coupling.
Service Abstraction
Service contracts should only contain information limited to what is published in service contracts. Service abstraction hides as much of the underlying details of a service as possible to maximize loose coupling. This principle is reminiscent of the dependency inversion principle.
Service Reusability
Reusable services with functionalities and data common to many applications should be maximally identified. As noted before, MSA discourages service reusability to maximize independence among services and to minimize update release cycles based on per-service deployment.
Service Autonomy
Service autonomy (i.e., independence among services) can be compromised by overlapping (i.e., non-normalized) service contracts, shared logic, shared database, and shared physical resources (e.g., servers). Microservice patterns such as keeping persistent data dedicated to a service and using event-based choreography instead of process orchestration aim at improving autonomy of services beyond conventional SOA services. Dedicated databases also facilitate polyglot persistence, allowing a more autonomous choice of data storage model for each service, as illustrated in Figure 6.
Service Statelessness
Services should minimize resource consumption by deferring the management of state information when necessary. The management of excessive state information for serving different clients and tasks can compromise the scalability and availability of a service. Services are therefore ideally designed to remain stateful only when required. We can use a set of dedicated database tables for temporary relocation of state information (viz., state deferral).
Service Discoverability
We should supplement services with communicative metadata and registered in service registry so that they can be effectively discovered and interpreted. For a large, complex MSA, a service mesh (e.g., Istio, Linkerd) can supply a dedicated infrastructure layer to handle service-to-service communication, including discovery, routing, and security.
Service Composability
Services should be effective composition participants. A composition controller service can be developed to compose other services. Alternatively, an orchestration platform (e.g., BPMN or BPEL engine) can be used to coordinate services to conduct a business process. Microservices prefer choreography based on pub/sub messaging to process-based orchestration.
Intel is exemplary in honoring SOA principles. The company established a guideline regarding web services that requires that: All software products and infrastructure (including commercial on-premise software, public SaaS, internally developed applications, private SaaS, private IaaS, public IaaS) should include a consumable API; APIs should be logically layered to provide useful abstraction; APIs should be discoverable at runtime; Functionality provided through CLI or GUI must also be available through an API, and furthermore implemented as wrappers for APIs; APIs should support role-based access with proper authentication and authorization; REST is preferred to SOAP; JSON is preferred to XML; There should be loose association between clients and API; Services should be stateless and all state data be returned to the client; Asynchronous messaging is preferred; Services should be fault-tolerant. Refer to: Intel IT, Maximizing Cloud Advantages through Cloud-Aware Applications, 2013. (https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/maximizing-cloud-advantages-through-cloud-aware-applications-paper.pdf)
SOA Service Design Patterns
A pattern for SOA or MSA is a general, reusable solution for, or a general practice to solve a commonly occurring problem in SOA or MSA. Certain practices are needed to realize a pattern. Each pattern realizes certain principles and provides certain values. We have discussed values and principles of SOA and MSA above in the MSA Benefits and Drawbacks, SOA Benefits, and Service-Oriented Architecture Principles sections.
SOA and MSA design patterns can be classified into service design patterns at the individual service level, service composition patterns at the business process or application level, and service inventory patterns at the enterprise level.
A service composition is an aggregate of services collectively composed to automate a particular business capability or business process. To qualify as a composition, at least two participating services plus one composition initiator need to be present. A service inventory is an independently standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise. Services for multiple solutions can be designed for delivery within a standardized, enterprise-wide inventory architecture wherein they can be freely and repeatedly recomposed. Refer to: Thomas Erl, SOA Design Patterns, Prentice Hall, 2009.
Let us start with service design patterns for SOA. Recall that SOA encompasses SOAP-based SOA and HTTP-Based SOA which includes MSA and Modulith. It will be noted if a service design pattern is a representative pattern for MSA; otherwise, the following patterns apply to all types of SOA.
Model-Driven Design
The identification of services in a business domain requires grouping into a service a set of business tasks (or use cases) and business objects that are closely related and together provide a discrete business capability. Service analysis activities, therefore, typically involve modeling of business processes, business semantics, business use cases, etc., and deriving a domain model based on those conceptual-level models. This domain model is used to define SOA services as discussed later in the bounded context pattern for specification-level SOA service design. This pattern is essential for supporting the service abstraction, composability, reusability, and loose coupling principles. The Complete Guide to Business Analysis (https://www.kosta-online.com/post/the-complete-guide-to-business-analysis) explains a systematic engineering process to derive the domain model from business models.
The domain model should be tightly related to the code giving the code meaning and making the model relevant. Model-driven design puts analysis and design in a single iterative loop so that a model faithfully express key concepts of the domain and at the same time practical for implementation. Development becomes an iterative process of refining the model, the design, and the code as a single activity. Refer to: E. Evans, Domain-Driven Design, 2003.
Object-oriented analysis, design, and programming with help of tools can serve this purpose. Java and many other tools allow the creation of objects and relationships directly analogous to business requirement models as shown in The Complete Guide to Business Analysis (https://www.kosta-online.com/post/the-complete-guide-to-business-analysis). With a model-driven design, a portion of the code is an expression in the model; changing that code changes the model. Programmers are modelers whether anyone likes it or not. So, it is better to set up the project so that the programmers do good modeling work. Refer to the hands-on modeler pattern for business analysis in Eric Evans, Domain-Driven Design, 2003, and The Complete Guide to Business Analysis (https://www.kosta-online.com/post/the-complete-guide-to-business-analysis).
Bounded Context
The concept of bounded context is defined in Eric Evans, Domain-Driven Design, 2003. Each service should have a explicitly defined context, called bounded context, within which a domain model expressing a ubiquitous language exists. Figure 7 shows an example of defining bounded contexts on a domain model. The domain model expressed in UML class diagram is partitioned into three packages, each being a bounded context. The domain model is explained in the Software Requirements Specification section in The Complete Guide to Business Analysis (https://www.kosta-online.com/post/the-complete-guide-to-business-analysis).
A ubiquitous language is a versatile, shared team language using the domain model as its backbone. Developers, domain experts and customers should use the same language in diagrams, code, writing and speech. The vocabulary of a ubiquitous language includes classes, prominent operations, rules, patterns, etc. You should relentlessly exercise the ubiquitous language to hammer out a shared view of the model as the concepts evolve in different people’s heads.
The bounded context pattern can be applied only if the service provider has adopted the model-driven design pattern. It also supports the service abstraction, composability, reusability, and loose coupling principles. Bounded contexts have a deeper influence on MSA, setting explicitly set boundaries in terms of team organization, and physical manifestations such as code bases and databases.
A bounded context may have multiple modules (or subdomains). In Figure 8, subdomains are in the problem domain, while bounded contexts are in the solution domain. The e-Commerce System might have been further decomposed into four bounded contexts (i.e., services). However, there are costs incurred by decomposing a service into finer-granule services. Integration across the boundaries of bounded contexts necessarily will involve translation, and more messages will be exchanged among the services.
Domain-Driven Design (DDD) recommends instituting a process of frequently merging all code and other implementation artifacts within a single bounded context, with automated tests to flag fragmentation quickly. Extreme programming (Kent Beck, Extreme Programming Explained, 2004) or called XP is recommended for maintaining model integrity within a single bounded context while the design is being constantly changed by many people. Figure 9 shows the practices recommended in XP. The Incremental Design, Test-First Programming, Ten-Minute Build, Continuous Integration and Daily Deployment practices are particularly important to develop and maintain high-quality applications in SOA and MSA.
Figure 10 shows a DDD-based approach to designing MSA developed by Microsoft. (Microsoft, Designing a DDD-Oriented Microservice: https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice) In the domain model layer, the domain entity model corresponds to a conceptual-level class diagram, and the domain entities with data + behavior corresponds to a specification-level class diagram explained in the Software Requirements Specification section in The Complete Guide to Business Analysis (https://www.kosta-online.com/post/the-complete-guide-to-business-analysis). Various object design patterns and DDD patterns are applied in this approach including the Command pattern (one of the 23 Gang of Four design patterns), the Command-Query Separation (CQS) pattern developed by Bertrand Meyer, and Aggregates and Repositories patterns in DDD.
Intention-Revealing Interface
Specify intention-revealing interfaces by naming classes and operations to describe their effect and purpose, not the means, with the effect of relieving the client developer of the need to understand the internals of services. Refer to: E. Evans, Domain-Driven Design, 2003. DDD recommends writing a test for a behavior before creating it, to force your thinking into client developer mode. This pattern follows the service abstraction principle of SOA.
Contract Centralization
Access to service logic is limited to the service contract, forcing consumers to avoid implementation coupling, and thus supporting the service loose coupling principle. Refer to: Thomas Erl, SOA Design Patterns, Prentice Hall, 2009.
Decoupled Contract
For a service to be positioned as an effective enterprise resource, it must be equipped with a technical contract that exists independently from its implementation yet still in alignment with other services. The service contract is physically decoupled from its implementation, and service functionality is limited to the feature-set of the decoupled contract medium, supporting the service loose coupling principle. (Ibid.) This pattern supports of the dependency inversion principle mentioned in the SOA Principles section above.
Concurrent Contracts
A service’s contract may not be suitable for or applicable to all potential service consumers. Multiple contracts can be created for a single service, each targeted at a specific type of consumer. (Ibid.) This pattern supports the interface segregation principle mentioned in the SOA Principles section above.
Service Façade
The façade pattern is a software design pattern commonly used with object-oriented programming. It is one of the 23 well-known GoF design patterns (Eric Gamma, Richard Helm, Ralph Johnson and John Vissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1994: https://en.wikipedia.org/wiki/Design_Patterns). The service façade pattern supports the service loose coupling principle and is used to realize the decoupled contract pattern as well as the concurrent contracts pattern. A service façade component can be added for the abstraction of core service logic from the contract. This allows multiple façades for the same service. The addition of the façade component introduces performance overhead though.
Service Adapter
The adapter (a.k.a. wrapper, service broker) pattern is also one of the 23 GoF design patterns that converts the interface of an existing class into another interface that another class requires without modifying their source code. While a service façade provides a more abstract interface for a service, a service adapter is an intermediary between two services that converts the interface of one to that of the other, and vice versa, so that incompatibility between the interfaces of two services is resolved.
Incompatibility between two services may lie in incompatible semantic models that may hold synonyms, homonyms, and other various semantic mappings between the two services. In this case the service adapter should convert data based on different data models at runtime. A metadata management is helpful to correctly transform data by the service adapters. Service adapters help maintain a federated database system where the constituent database systems are interconnected, and yet remain autonomous. Other sources of incompatibility include disparity in data format (e.g., CSV, XML, WSDL, REST) and that in communication protocols (e.g., XMK-RPC, JSON-WSP, SOAP). Service adapters also supports the service loose coupling principle and is used to realize the decoupled contract pattern as well as the concurrent contracts pattern.
Anti-Corruption Layer (ACL)
Wrapper services required to encapsulate legacy logic often introduce a non-standard service contract requiring high technology coupling throughout all service consumer programs. The non-standard wrapper service can be replaced by or further wrapped with a standardized service contract that extracts, encapsulates, and eliminates legacy technical details from the contract.
ACL (a.k.a. legacy wrapper) is the isolating layer consisting of the standardized service contract and required service logic. ACL needs to be developed (or provided by software product vendors) as a service façade or a service adapter to abstract the proprietary legacy interface. The layer talks to the legacy system through its existing interface, requiring little or no modification to the legacy system. Internally, the layer translates in both directions as necessary between the two domain models. This pattern is a special case of the service façade pattern and the service adapter pattern. Refer to: Ibid. and Eric Evans, DDD, 2003.
Hexagonal Architecture
In many software applications business logic infiltrated into the user interface code. The problem (a.k.a. smart UI anti-pattern) occurs often because part of the logic needing to be tested is dependent on oft-changing visual details. The problem makes it difficult to shift from a human-driven use of the system to a batch-run system or to a program to be driven by another program. Besides, a bounded context can have multiple technical services realized through RESTful resources, SOAP interfaces, message types, DB accesses, etc.
We should create a service to be independent of either UI or database and to provide adapters for different input / output sources such as GUI, DB, test harness, RESTful resource, etc. The hexagonal architecture pattern can be applied to that end. As can be seen in Figure 13, as events arrive at a port, an adapter (a.k.a. service agent pattern) converts it into a procedure call or message and passes it to the application. When the application has something to send out, it sends it out through a port to an adapter, which creates the appropriate signals needed by the receiver. This pattern realizes both the decoupled contract pattern and the concurrent contracts pattern. Refer to: Alistair Cockburn, Hexagonal Architecture, 2005. (http://alistair.cockburn.us/Hexagonal-architecture)
HATEOAS
Use cases the client needs are often highly likely different from the pure domain model. In this case, the API model should be decoupled from the core domain to maintain the service loose coupling principle of SOA. The API can be a set of REST resources reflecting the use cases the client needs. Yet each resource is built from classes belonging to the core domain.
REST API compliant with the HATEOAS pattern may further remove coupling between clients and services. HATEOAS (Hypertext As The Engine Of Application State) is the highest maturity level of REST in the REST maturity model proposed by Leonard Richardson. HATEOAS is a pattern of REST application architecture where a client enters a REST application through a specific URL, and all future actions the client may take are discovered within resource representations returned from the server. In this way, REST interaction is driven by hypermedia with self-contained discoverability. (https://spring.io/projects/spring-hateoas)
This is different from the WSDL-driven interface of conventional SOA applications which is a fixed specification staged somewhere in a service registry. One obvious benefit of HATEOAS is that the service provider can change the service’s capabilities without breaking clients. The service provider can freely add and juggle all URIs other than the initial entry points. (https://martinfowler.com/articles/richardsonMaturityModel.html) This pattern realizes the decoupled contract pattern.
Service Data Replication
Service logic can be deployed in isolation to increase service autonomy, but services continue to lose autonomy when requiring access to shared data sources. Services can have their own dedicated, materialized views with replication to shared data sources without requiring exclusive ownership over the data. An additional database needs to be provided for the service and one or more replication channels need to be enabled between it and the shared data sources.
Service Data Separation (Database per Service)
Sharing an integrated database among services have a few drawbacks: First, you cannot change the database schema without affecting the services. Second, you cannot change the database technology (e.g., from relational to NoSQL) for different services. Third, the same sorts of logic to process data can be spread among multiple services.
The service data separation pattern splits the database and allocate the partitions to individual services. Services now owning their databases are better decoupled from other services. Accesses to the database owned by another service is done via API calls. Join queries involving tables owned by different services now need to be processed in memory (see Figure 15). You also face the problem of maintaining integrity across related tables owned by different services. You must implement cross-table constraints such as referential integrity, assertions and triggers in your service code.
This pattern is an essential pattern for MSA, facilitating independent deployment and independent scalability of individual services.
When a database is split across many services, a transaction involving write operations on multiple separate databases requires complex processing to achieve ACID properties. You can attain only BASE (Basically Available, Soft state, Eventual consistency) semantics in contrast to ACID guarantees provided in a monolithic database, according to the CAP (Consistency, Availability, Partition Tolerance) theorem. Refer to related patterns in the SOA Service Composition Patterns section below: atomic transaction pattern, transaction compensation pattern, choreography pattern, and publish-and-subscribe messaging pattern. Refer to: Sam Newman, Building Microservices: Designing Fine-Grained Systems, 2015.
Command and Query Responsibility Segregation (CQRS)
Operations can be broadly divided into two categories — commands (i.e., updates) and queries. Updates may leave side effects (i.e., any unintentional effect on the state of the system) and may better be segregated from queries. Place as much logic as possible into functions (i.e., operations that return results without producing side effects) and make them separate services. Strictly segregate commands into quite simple operations that do not return domain information. Either the service data replication pattern or the service data separation pattern can be used for realizing CQRS.
Martin Fowler warned, “CQRS is a significant mental leap for all concerned, so shouldn’t be tackled unless the benefit is worth the jump. While I have come across successful uses of CQRS, so far, the majority of cases I’ve run into have not been so good, with CQRS seen as a significant force for getting a software system into serious difficulties. In particular CQRS should only be used on specific portions of a system (i.e., bounded contexts) and not the system as a whole. In this way of thinking, each bounded context needs its own decisions on how it should be modeled.” Refer to: Greg Young, CQRS, Task Based UIs, Event Sourcing agh!, 2010 (http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/); Martin Fowler, CQRS, 2011 (https://martinfowler.com/bliki/CQRS.html).
SOA Service Composition Patterns
Most enterprise systems are tightly integrated systems spanning the entire business. The challenge is to accomplish modularity without losing the benefits of integration, allowing different parts of the system to interoperate to support the coordination of various business processes.
Context Map
People on other teams will not be very aware of the context boundaries and will unknowingly make changes that blur the edges or complicate the interconnections. Identify and name each model on the project and define its bounded context. Determine which modules belong in which context. Map the existing terrain.
Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing. You need to determine which composition patterns to apply in integrating services. Refer to: Eric Evans, Domain-Driven Design, 2003.
Service-Responsibility-Collaboration
CRC(Class-Responsibility-Collaboration) card game is a popular object design practice for allocating operations needed in use cases to classes and also determining which classes should collaborate to realize each operation. Refer to the Class Responsibility Assignment pattern in The Complete Guide to Business Analysis (https://www.kosta-online.com/post/the-complete-guide-to-business-analysis).
The same card format as the CRC card can be used to show the interface of a service and the other services that each operation in the interface need to be collaborate with. A stack of SRC cards will correspond to a context map. Figure 18 shows a SRC card for an Insurance Policy Management service whose Calculate Premium method need to collaborate with three other services.
Shared Kernel
Uncoordinated teams working on closely related applications can go racing forward for a while, but what they produce may not fit together. They can end up spending more on translation layers and retrofitting than they would have on continuous integration in the first place, meanwhile duplicating effort and losing the benefits of a common ubiquitous language. Designate some subset of the domain model that the two teams agree to share. Of course, this includes, along with this subset of the model, the subset of code or of the database design associated with that part of the model. This explicitly shared stuff has special status and shouldn’t be changed without consultation with the other team. Integrate a functional system frequently, but somewhat less often than the pace of continuous integration within the teams. At these integrations, run the tests of both teams. Refer to: Eric Evans, Domain-Driven Design, 2003.
Customer/Supplier
The freewheeling development of the upstream team can be cramped if the downstream team has veto power over changes, or if procedures for requesting changes are too cumbersome. The up-stream team may even be inhibited, worried about breaking the downstream system. Meanwhile, the downstream team can be helpless, at the mercy of upstream priorities.
Make the downstream team play the customer role to the upstream team. On an XP project, there already is a mechanism in place for doing just that: the iteration planning process. All we must do is define the relationship between the two teams in terms of the planning process. Jointly develop automated acceptance tests that will validate the interface expected. Add these tests to the upstream team’s test suite, to be run as part of its continuous integration. This testing will free the upstream team to make changes without fear of side effects downstream.
Figure 20 shows a context map where the role of each service in the relationship between a pair of services is specified as either upstream or downstream, and the pattern of service composition to be applied to the pair is specified. Refer to: Dino Esposito and Andrea Saltarello, Microsoft .NET: Architecting Applications for the Enterprise, Microsoft Press, 2014.
Conformist
When two development teams have an upstream/downstream relationship in which the upstream is not motivated to provide for the downstream team’s needs, the downstream team is helpless. Eliminate the complexity of translation between bounded contexts by slavishly adhering to the model of the upstream team. Also, you will share a ubiquitous language with your supplier team. If these trade-offs are not acceptable, but the upstream dependency is indispensable, the second option remains: Insulate yourself as much as possible by creating an anticorruption layer, an aggressive approach to implementing a translation map.
Separate Ways
Integration is always expensive. Sometimes the benefit is small. Just because features are related in a use case does not mean they must be integrated. Declare a bounded context to have no connection to the others at all. The features can still be organized in middleware or the UI layer.
Open Host Service
When a subsystem has to be integrated with many others, customizing a translator for each can bog down the team. There is more and more to maintain, and more and more to worry about when changes are made.
Define a protocol that gives access to your subsystem as a set of services. Open the protocol so that all who need to integrate with you can use it. Other teams are forced to learn the particular dialect used by the host team. In some situations, using a well-known published language as the interchange model can reduce coupling and ease understanding.
Asynchronous Service Messaging
Various asynchronous messaging mechanisms can be applied to exchange messages among services. Queuing allows services to exchange messages via an intermediary buffer so that the services process messages independently by remaining temporally decoupled. In SOAP-based SOA, this pattern is implemented by a combination of the WS-Reliable Messaging standard, Enterprise Service Bus (ESB), and guaranteed delivery extensions, such as a persistent repository. In HTTP-based SOA, this pattern is implemented by publish-and-subscribe message brokers such as RabbitMQ, Apache Kafka, Redis, Amazon SQS/SNS, etc.
Enterprise Service Bus
An enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability, scalability, and communications disparity. Enterprise service bus (ESB) is comprised of the co-existent application of many service design and composition patterns such as service adapter, asynchronous service messaging, publish-and-subscribe messaging, policy centralization, and rules centralization patterns. Refer to: T. Erl, SOA Design Patterns, 2009. ESB is a core component of SOAP-based SOA. In HTTP-based SOA ESB can be replaced by an iPaaS (Integration Platform as a Service).
Publish-and-Subscribe Messaging
Events that occur within the functional boundary encapsulated by a service may be of relevance to other services, but without resorting to inefficient polling-based interaction, the other services have no way of learning about these events. The related other services establish themselves as subscribers of the service. The service, in turn, automatically publishes notifications of relevant events to its subscribers. A messaging framework is implemented capable of supporting publish-and-subscribe message exchange and associated complex event processing.
Service Orchestration
Service orchestration integrates multiple services together to automate a process, creating a composite application. Orchestration environments such as Business Process Management Suite (BPMS) products supporting BPMN 2.0 modeling, BPMN 2.0 execution, and WS-BPEL execution support sophisticated and complex service composition logic that can result in a long-running runtime process. The orchestration pattern is a composite pattern comprised of several other service design, composition and inventory patterns including process abstraction, process centralization, rules centralization, service adapter, atomic service transaction, compensating service transaction, and state repository patterns. SOAP-based SOA has used this pattern together with the ESB pattern. Refer to: T. Erl, SOA Design Patterns, 2009. HTTP-based SOA uses both the orchestration and the choreography explained next.
Service Choreography
Service choreography is another way to create a composite application in SOA. A service choreography model works without a central orchestrator. In service choreography, the participating services each know the business logic and sequence and timing of message exchanges, while in service orchestration, the participating services do not know that they are being orchestrated as part of a higher-level service; only the central controller knows the business logic and messaging sequence. In service choreography, the logic of the message-based interactions among the participants is specified from a global perspective, while in service orchestration, the logic is specified from the local point of view of one single participant, called the orchestrator.
We must deal with the problem of managing business processes that stretch across the boundaries of individual services. With microservices we hit this limit sooner than usual. While with orchestration we rely on a central coordinator like the conductor in an orchestra, with choreography each service works out the details like dancers in a ballet. A service publishes an event in an asynchronous manner, and other services subscribe to the event and react accordingly.
This approach based on the publish-and-subscribe messaging pattern is more decoupled because some other services needing to react to the event can just subscribe to it. However, a service always needs to know which events published by other services it should subscribe to. In this aspect, choreography makes services tightly coupled.
BPMN 2.0 can be used to model both orchestration and choreography. Activities, gateways and sequence flows can be used to model orchestration, and event throw-and-catch patterns can be used to model choreography.
In a single application, we can choose either orchestration or choreography for each use case (or process activity) to compose it into the business process. In Figure 22, the Check Out process (i.e., orchestrator) orchestrates the Process Payment and Ship Ordered Products services. The Update Inventory and Cancel Payment services are choreographed using a pub/sub channel Kafka.
In HTTP-based SOA, usually, orchestration is used for long and complex processes, while choreography is used for relatively short and simple processes. Choreography is more difficult to manage than orchestration for long and complex processes. Due to the lack of central visibility and control, choreography is more difficult to do troubleshooting, error recovery and process change.
Atomic Transaction
When a short-lived transaction that spans multiple services fails, the changes made to the database up to that point may compromise the integrity of the database. If a single database is shared among all services, those services can be wrapped in a transaction with rollback feature that resets all changes if the transaction cannot be successfully completed.
For SOAP-based SOA, this pattern is supported by WS-Coordination and WS-Atomic Transaction standards, and a transaction manager inside an ESB (explained in the enterprise service bus pattern above) can be used for rollback of short-lived transactions.
This pattern is not easily supported in MSA because databases are distributed across services. If we want to guarantee transaction atomicity for distributed transactions in MSA, we should apply the two-phase commit (2PC) protocol. However, 2PC is not generally recommended for MSA because its synchronous, blocking nature conflicts with the need for high availability, scalability, and loose coupling in MSA. Instead of 2PC, the alternative Saga pattern explained below is often used in MSA to manage distributed transactions with eventual consistency. As explained in the service data separation pattern, if a database is split across many services, you can attain only BASE (Basically Available, Soft state, Eventual consistency) semantics in contrast to ACID guarantees provided in a monolithic database, according to the CAP (Consistency, Availability, Partition Tolerance) theorem.
Transaction Compensation
For long-lived transactions, wrapping the service composition in an atomic transaction can tie up too many resources, negatively affecting performance and scalability. Compensation routines are introduced, allowing runtime exceptions to be resolved with the opportunity for reduced resource locking and memory consumption. Compensation logic is pre-defined and implemented as part of the composition controller logic such as process orchestration (explained in the service orchestration pattern). For SOAP-based SOA, WS-BPEL and WS-Business Activity standards provide functionality in support of this pattern. This try-later approach promises that the system will get itself back into a consistent state eventually.
Saga
In MSA, 2PC protocol is unsuitable especially for long-lived transactions due to performance overhead and blocking nature. Instead, atomicity for long-lived distributed transactions is typically managed using the Saga pattern. The Saga pattern manages a sequence of local, independent transactions across different services. Atomicity is ensured not by a global lock, but by executing a series of compensating actions to undo previous changes if any step in the sequence fails.
If orchestration is used for service composition, the orchestrator (viz., a controller service or a BPMN process) manages the transaction’s workflow and state. The orchestrator sends commands to participating services telling them what local transaction to execute. If a participant reports a failure, the orchestrator issues commands for the appropriate compensating actions to roll back the entire process.
If choreography is used for service composition, each service publishes domain events upon the completion of its local transaction, which triggers the next service in the sequence to perform its operation. If a service fails, it publishes an event indicating the failure, and other services react by executing their respective compensating actions.
API Composition for UI
Think of user interfaces as composition layers — place where we weave together the various strands of the capabilities we offer. Have your user interfaces directly make API calls and map them to UI controls (e.g., web-based UI using JavaScript to get JSON via HTTP). This approach could require fairly chatty communication, and could drift back into old, layered architecture where UIs and APIs are tightly coupled. Refer to: Sam Newman, Building Microservices: Designing Fine-Grained Systems, 2015.
Backends for Frontends
The Backend For Frontend pattern uses the API Composition for UI pattern to create a dedicated backend service for each specific user interface. This makes each service more self-contained and independent with its own UI and own backend. Just beware of the backends infiltrating into the domain logic which must stay with the services themselves. The backends should only contain behavior specific to delivering a particular user experience. (Ibid.)
Fragment Composition
Have your services supply parts of the UI directly and then just pull these fragments in to create a UI. These coarse-grained fragments are served up from server-side apps that are in turn making the API calls. You still need some sort of assembly layer to pull these parts together. This could be some server-side templating or some smart URI routing. Drawbacks of this approach are that some techniques such as style guides need to be added to ensure consistency of UX, and that it cannot easily serve diverse types of UI such as mobile devices, native apps, thick clients, dynamic UI, etc. (Ibid.)
Microfrontend
The Microfrontend pattern relies on the UI Fragment Composition pattern. The microfrontend pattern is used by DevOps teams for MSA. The teams own separate, deployable UI fragments and may use different UI composition frameworks. The fragments are built and deployed independently and assembled into one UI in production (at runtime).
API Gateway for UI
A common solution to the problem of chatty interfaces with backend services, or the need to vary content for different types of devices is to have a server-side aggregation endpoint, or API gateway.
This can marshal multiple backend calls, vary and aggregate content if needed and serve it up. The gateway could end up too thick with too much behavior infiltrating into the domain logic and start losing isolation of various user interfaces limiting your ability to release them independently. (Ibid.)
SOA Service Inventory Patterns
A service inventory is an independently standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise. Services for multiple solutions can be designed for delivery within a standardized, enterprise-wide inventory architecture wherein they can be freely and repeatedly recomposed. Refer to: Thomas Erl, SOA Design Patterns, Prentice Hall, 2009.
Service-Oriented Enterprise Application Architecture
A service-oriented enterprise application architecture encompass service inventories. Establishing an single enterprise service inventory may be unmanageable, and attempts to do so may jeopardize the success of an SOA adoption. Services can be grouped into manageable, domain-specific service inventories, each of which can be independently standardized, governed, and owned. However, standardization disparity between domain service inventories imposes transformation requirements and reduces the overall benefit potential of the SOA adoption.
A service inventory has runtime platforms and middleware and represents a concrete boundary for a standardized architecture implementation. Services are delivered into a service inventory from which service compositions are drawn. Services are composed solely based on service contracts into fully functional applications.
Layered Service-Oriented Architecture
To achieve enterprise-wide loose coupling, collections of services representing corporate business logic and those of technology-specific application logic can be physically separated. Business services can be further classified into task-centric business services (a.k.a. task services) and entity-centric business services (a.k.a. entity services). Entity services are agnostic business services reusable across many business processes that base their functional context on existing business entities. Task services encapsulate non-agnostic business logic specific to a business process.
Task services can be centralized as part of a business process layer (or an orchestration layer). Orchestration combines business process models with SOA models and enables workflow automation. SOAP-based SOA applies this layered architecture pattern as shown above in Figure 3 and again below in Figure 29. (Thomas Erl, Service-Oriented Architecture: Concepts, Technology and Design, Prentice Hall, 2005.)
Members of each layer are aware of and are able to use the services of the layers below (any lower layer, not just one immediately below), but unaware of and independent of the layers above. (Buschmann et al. Pattern-Oriented Software Architecture, 1996)
In Domain-Driven Design (DDD), an SOA application is also intentionally structured into responsibility layers that separate pure business logic from infrastructure concerns. Figure 30 shows an example of layered service-oriented architecture with four layers for a cargo shipping application adopted from E. Evans, Domain-Driven Design, 2003. DDD refactors the domain model across bounded contexts so that the responsibilities of each domain object, aggregate and module fit neatly within the responsibility of one layer.
If choreography is used instead of orchestration for composing services into a business process as preferred in MSA, the business process is no longer explicitly visible as a separate layer and cannot controlled top down. Instead, task services are pushed into service themselves, and connected bottom up through publish-and-subscribe event messaging.
Service Normalization
When delivering services as part of a service inventory, there is a constant risk that services will be created with overlapping functional boundaries. The service inventory needs to be designed with an emphasis on service boundary alignment. Ensuring that service boundaries are and remain well-aligned introduces an extra up-front formal service modeling, and on-going governance effort. The next section titled SOA Service Analysis & Design Methodologies shows formal service modeling. Refer to: T. Erl, SOA Design Patterns, 2009.
Logic Centralization
If agnostic services are not consistently reused, redundant functionality can be delivered in other services, resulting in problems associated with inventory denormalization and service ownership. SOA governance must be established so that service consumers should use a single designated agnostic service to access the reusable functionality. Refer to: Ibid.
Policy Centralization
Policies that apply to multiple services can introduce redundancy and inconsistency within service logic and contracts. Global or domain-specific policies can be isolated and applied to multiple services. Up-front analysis specific to defining reusable policies is recommended, and a suitable policy enforcement framework is required. Also required is a governance structure with policy custodian roles and processes to control changes to shared policies and avoid conflicts and incompatibilities between different policies. Refer to: Ibid.
Rules Centralization
Policies tell what must be true in an organization, and rules tell how policies are enforced. The same business rules may apply across different business services, leading to redundancy and governance challenges. The storage and management of reusable business rules should be positioned within a dedicated architectural extension from where they can be centrally accessed and maintained. Business rules management systems (BRMS) is often used to support this pattern. Refer to: Ibid.
Schema Centralization
Different service contracts often need to express capabilities that process similar business documents or data sets, resulting in redundant schema content that is difficult to govern. Select schemas that exist as physically separate parts of the service contract can be shared across multiple contracts. Up-front service analysis effort is needed to establish a schema layer independent of and in support of the service layer. The next section titled SOA Service Analysis & Design Methodologies shows service analysis methods. Refer to: Ibid.
Process Centralization
As discussed in the Layered Service-Oriented Architecture pattern above, task services can be centralized into the business process layer. Refer to: Ibid.
API Centralization
APIs enable A2A and B2B integration, multichannel applications, service-oriented architecture, cloud services and the reuse of legacy applications and data — viz., pervasive integration of mainframe, databases, big data, cloud services, mobile apps, social networks, connected devices, etc. Adopt API mediator to virtualize, enable, control, protect and monitor APIs. The API mediation layer encapsulates a service’s native API (the inner API) and exposes an abstracted and managed API (the outer API) to all potential consumers.
API mediator may be built using a variety of technologies, such as API gateways, cloud access security brokers (CASB), mobile back-end services (MBaaS), integration platform as a service (iPaaS), and enterprise service buses (ESBs). API management tools can be used to implement the API mediator, which are now deemed essential for digital business. Full lifecycle of API management is about planning, design, implementation, publication, operation, consumption, maintenance and retirements of APIs. Refer to: Gartner, Mediated APIs: An Essential Application Architecture for Digital Business, 2016; Gartner, Use Mediated APIs to Connect Your Legacy and Packaged Systems with Modern Applications, 2016; Gartner, Magic Quadrant for Full Life Cycle API Management, 2016.
Core Domain
A large complex domain, such as a business domain in an enterprise, requires model distillation — a process of separating the components of a mixture to extract the essence in a form that makes it more valuable and useful. Find the core domain and distinguish it from the mass of supporting model and code. Bring the most valuable and specialized concepts into the core domain but make it small. Refer to: E. Evans, Domain-Driven Design, 2003.
In Figure 30 above, Routing, Commitments, Routing Policy, Shipment, and Banking are core domains while the other services are generic subdomains explained next. The core domain can be partitioned into coherent packages of their own (called segregated core).
Generic Subdomain
You should identify cohesive subdomains that can be horizontally used across multiple applications or across different verticals. Factor out generic models of these subdomains and place them in separate modules. Consider off-the-shelf solutions (such as open-source code, public SaaS, commercial products, frameworks), published models (such as industry reference models, analysis patterns) or outsourced implementation for these generic subdomains.
Pluggable Component Framework
Distill an abstract core of interfaces and interactions and create a framework that allows diverse implementations of those interfaces to be freely substituted. Allow any application to use it strictly through its interfaces. Refer to: Ibid.
COTS/SaaS Integration
Build if the business capability is unique to what you company does and is considered a strategic asset; buy if it is not that special and can benefit from global best common practices. If you decided to buy a COTS product or subscribe to a SaaS but the capabilities it provides are not specialized for your needs, it might make sense to change how your company should work rather than embark on complex customization.
You need to select COTS and SaaS which are easy to integrate with and customize through APIs. But technical decisions have been made for you by the vendors, and the key is to move things back on to your own terms. Refer to: Sam Newman, Building Microservices: Designing Fine-Grained Systems, 2015.
Evolving Order
Let the large-scale structure of enterprise application architecture across bounded contexts evolve with the application, possibly changing to a completely different type of structure along the way. Do not overconstrain the detailed design and leave freedom for development teams in distinct contexts to vary the model in ways that address their local needs. Refer to: E. Evans, Domain-Driven Design, 2003.
Knowledge Level (a.k.a. Meta Level)
Create a distinct set of objects that can be used to describe and constrain the structure and behavior of the basic model. Keep these concerns separate as two levels, one very concrete, the other reflecting rules and knowledge that a user can customize. Figure 32 shows a domain model of an EMR system where the bounded context Clinical Pathway constitutes a knowledge-level service. Refer to: Ibid.
SOA Analysis & Design Methodologies
SOA analysis and design methodologies have been developed by several ISVs (Independent Software Vendors) like Microsoft and ESPs (External Service Providers) like IBM Consulting. Figure 33 shows the SOMA (Service-Oriented Modeling and Architecture) methodology developed by IBM Consulting in 2004. Refer to: IBM, Building Service-Oriented Banking Solutions with IBM Banking Industry Models and Rational SDP, 2007. (http://www.redbooks.ibm.com/abstracts/redp4232.html) It uses business process model, data model and use case model for service analysis and design. Business process activities are mapped to use cases, and use cases and data entities are clustered to make services.
Figure 34 shows SOA analysis and design methodology used by Microsoft. Refer to: Microsoft, Connected Health Framework Architecture and Design Blueprint: Part 2-Business Framework, 2009. It also uses business process model, data model and use case model to identify services. It conducts the affinity analysis to cluster use cases and data entities into services.
Figure 35 shows the SOA analysis and design methodology called Ignite to develop complex enterprise IoT solutions in Bosch, the largest automotive supplier in the world. Refer to: D. Slama, et al., Enterprise IoT: Strategies and Best Practices for Connected Products and Services, 2015. It also uses business process model, data model (input to domain model), use case model, and domain model to identify and design services. We can see that SOA analysis and design methodologies are the same among different companies.
SOA analysis methodology (including the affinity analysis) is explained in detail in The Complete Guide to Business Analysis (https://www.kosta-online.com/post/the-complete-guide-to-business-analysis) where we took a public software training business as an example to illustrate work products produced in business analysis (BA) to develop SOA applications.
The illustrated BA work products included business motivation model, business architecture model, business service model, business process model, business semantic model, business use case model, affinity analysis model, and use case scenarios. The business motivation model, business architecture model, and business service model are specified using ArchiMate, a standard enterprise architecture modeling notation developed by TOGAF. (https://www.opengroup.org/archimate-forum/archimate-overview) The business process model is designed using Business Process Model and Notation (BPMN), a standard business process modeling notation developed by OMG. (https://www.bpmn.org/) The business semantic model and business use case model are described using Unified Modeling Language (UML), a standard for visualizing, specifying, and documenting software and systems, also developed by OMG. (https://www.omg.org/uml/)
Work products from the subsequent object design activities were also illustrated using the same example, including a domain model and a sequence diagram, both in UML. Figure 36 shows bounded contexts identified on the domain model of the Public Software Training business. The figure therefore is a context map showing SOA services in that business domain.
Figure 37 shows a service interface diagram for the Course Scheduling Service expressed in SoaML. (See OMG, Service Oriented Architecture Modeling Language Specification, 2012. https://www.omg.org/spec/SoaML/) The Course Scheduling Service here corresponds to the Course Scheduling Service identified in the business architecture model shown in Figure 5.D in The Complete Guide to Business Analysis. The operations listed in the Course Scheduling Capability include all the operations belonging to the classes that are included in the bounded context corresponding to the service. Message types of the service are also defined using classes and attributes defined in the domain model.
Figures 6–12 in The Complete Guide to Business Analysis and Figures 36–37 here represent a bottom-up approach to SOA design where the domain model is developed first at a detail level and then bounded contexts, i.e., SOA services, are identified as groups of classes in the domain model. On the other hand, Figures 5.A to 5.D showing business modeling, business architecture design and business service identification in The Complete Guide to Business Analysis represents a top-down approach to SOA analysis. You may apply both top-down and bottom-up approaches in an evolutionary manner. When your project is a brownfield engineering project and tries to reuse proven functionalities in the legacy applications, the bottom-up approach is unavoidable. Even in this case, the top-down approach is helpful to ensure that your business goals, strategies, and to-be business models are realized as planned.
Figure 38 shows a service architecture diagram in SoaML that describes the service-oriented architecture of the entire business domain. Three services participate in the SOA landscape, which are orchestrated by the Public Software Training Process. There are inter-service interactions (of course via APIs) between Course Development Service and Course Scheduling Service, and between Course Scheduling Service and Class Booking & Operation Service.
Figure 39 shows a sequence diagram for the Schedule Courses process activity (shown in Figure 6.A in The Complete Guide to Business Analysis) which corresponds to the Make a Course Schedule use case (shown in Figure 8 in The Complete Guide to Business Analysis). The Schedule Courses process activity uses two internal services — Course Scheduling service and Course Development service, and uses two external services — Shared Calendar service and Booking service. The sequence diagram describes how SOA services are orchestrated by the business process or collaborate to realize the use case. Methods of the classes comprising each service are included in the API of the service as shown by check marks in Figure 39.
Refer to: Figures 5 to 12 in The Complete Guide to Business Analysis (https://www.kosta-online.com/post/the-complete-guide-to-business-analysis) to understand the context of the Public Software Training business.
Comments