By Cheng Yan (Nickname: Dingyi)
What are the similarities and differences among mainstream architectures, such as layered architectures, microservices architectures, and distributed architectures? What is a service-oriented architecture (SOA)? Why do we need SOA? What is the nature of service orientation? How should we design services and service-oriented architecture?
In this thorough and insightful article, Cheng Yan (nickname Dingyi), a senior technical expert at Alibaba, elaborates on his views about SOA and proposes a path to success for service orientation.
Since SOA came into the spotlight, I think that there have been no breakthroughs of particular significance in terms of software architecture design, whether involving service-based enterprise architectures, layered architectures, or microservice architectures. All of these are iterative upgrades built on top of service-oriented architecture to accommodate different scenarios.
My point is that the nature of service-oriented architecture is akin to the educational philosophy proposed by the ancient Greek philosopher Socrates, a philosophy that deeply influenced Western education. In a nutshell, Socrates' theory of "midwifery" emphasizes that education is a process of "delivery" and teachers are akin to "midwives". Therefore, people who are seeking education aim to find their "true selves" and continuously improve themselves. That is, the purpose of education is not to create but to awake the "true self". Similarly, the nature of the service-oriented architecture is not just about what we can create and implement using some technical framework, but more importantly about continuously retracing, abstracting, summarizing, inducing, and deducing the nature of the business while we work together to create architecture through self-questioning, introspection, and retrospection. Every architect is a midwife of service-oriented architecture and on a mission to build architecture that truly reflects the nature of its business and drives it to advance.
Do we fully understand the nature of the business? Have we adequately conducted induction, deduction, and comprehensive abstraction? Does our work clearly reflect the foundations of service orientation, including the business model, the domain model, and the platform-based public semantic model? These are the first and fundamental questions that every product designer, architect, team leader, or core developer involved in the development of a service-oriented architecture must answer.
Service-Oriented Architecture (SOA) – SOA is an architectural style dedicated to using the services that ensure the consistency of business functions as the basic unit to design, construct, and orchestrate business processes and solutions.
What do we need SOA for?
To achieve greater reusability? To divide responsibilities more easily? To separate interfaces and implementations for greater flexibility and isolation? For more effective interface classification and management?
Each of the answers above has some truth, but the purpose of SOA goes far beyond the design and definition of interface details. Its core focus is on the business description and the meaning of services, not design and implementation.
In addition, SOA is not about how to construct a service. Anyone can easily create a service. This is not the core challenge involved in building an SOA. It is about how to empower enterprises to build a collection of services with meaningful business value and complete business semantic significance.
SOA is designed to create services driven by business functions in diverse business environments within an enterprise to assemble the services into valuable and higher-level processes and solution platforms.
The real value of the SOA lies in agile and flexible business processes assembled and orchestrated by reusable services. Its agility is reflected with services that can be rapidly adjusted and independently evolved, and its flexibility is reflected with services that can be flexibly assembled. This flexibility of service assembly is possible because services have explicitly defined business functions, clearly established boundaries, and strong functional cohesion, in addition to their independent and complete lifecycles.
An SOA can create significant value for enterprises. The next section considers how this value is represented.
SOA allows us to use one unique entry for business processes, tasks, or decisions. This means the business behaviors involving the provision of services to the business are consistent regardless of the channel used to access the services.
An SOA allows us to use one single portal for access to business data information. This means it provides a public data access service that is aligned with the business by internal consensus within the enterprise.
SOA provides an effective mechanism for the modularization of business functions, business decisions, and business information. In addition, when modularization is effectively implemented, the modules can be flexibly reused and reassembled in various business processes and scenarios, thus supporting business competitiveness and creativity in a flexible and agile manner.
SOA integrates business functions and information while reducing the dependency and coupling between the two. This means independent business functional units and application systems can work together while each pursues its own evolution plan, lifecycle, and business objectives.
SOA supports business objectives at the service module granularity defined by service level agreements, allowing us to continuously set, monitor, and optimize components and assess services supported by applications and systems.
Behavioral consistency and data consistency are the foundations of service value.
First, we need to define the term service.
A service is an independent unit that provides business functions by means of a service contract. A service is also bound by the service contract.
Services are the basic units used to design, construct, and orchestrate business solutions in a complete business entity. A service contract specifies all interaction agreements between a service consumer and a service provider, including:
How are services different from modules, components, and other parts of software? The main difference is that services themselves, along with their service quality and performance, are explicitly managed through service level agreements, while modules and components are not subject to such constraints. In addition, the full lifecycle of a service, from design and deployment to enhancement, upgrade, and maintenance can be managed.
Examples (the following services are used for demonstration only and are not considered for real scenarios):
| Service | Service Strategy | Service Quality | Performance Requirements |
|---|---|---|---|
| Inventory replenishment calculation and recommendation service | Calculate and recommend inventory replenishment by merchants and suppliers in the industry | As long as sales projections meet the distribution and accuracy requirements, the recommended replenishment quantity generated according to the stock-out rate service level shall comply with the expected inventory turnover days | 100,000+ products * 30 warehouses; recommended inventory replenishment quantity for specific products and warehouses <= 30min |
| Order creation service | Support orders placed through the shopping cart and orders directly placed from the product page; create orders after all the discounts are calculated and applied | Order creation success rate: 99.999999999% or above | Peak capacity: 1 million orders per second |
A service itself consists of two main components. The first is the interface, which is the core of the service. The other is the service implementation. SOA effectively separates interfaces from implementations.
1) Service Interfaces
The service interface specifies the operation of the service. This includes what the service does, the input and output parameters of the operation, and the protocols used to specify how to use and provide these capabilities.
The service is usually built around a core business function operation and its associated operations. For example, the core operation of the Inventory Replenishment Calculation and Recommendation Service is to generate a replenishment recommendation order for specific products and warehouses.
Its associated operations include querying sales forecasts related to the replenishment order and performing inventory planning operations corresponding to the replenishment order.
| Service | Core Functional Operation | Associated Operations |
|---|---|---|
| Replenishment Calculation and Recommendation Service | ||
| Calculate inventory replenishment recommendations for specific products and warehouses | ||
| Query sales forecasts corresponding to the replenishment order | ||
| Perform inventory planning operations corresponding to the replenishment order |
2) Service Implementation
Service implementation refers to how a service provides its capabilities through well-defined interfaces. A service can be implemented:
The key to service implementation is that it is transparent to the service consumers who only need to focus on what the service does, rather than how the service is implemented.
As long as service interfaces or behavioral agreements remain unchanged, the service can be implemented in various ways to accommodate the needs of different industries and scenarios.
Under the same conditions, the service can be upgraded and switched without restrictions. To meet diverse needs, service implementations can be switched through static upgrades or in real-time through dynamic routing. For instance, the service can be automatically switched to satisfy the needs of specific industries and business scenarios.
No matter how the service is switched by upgrading or automatic routing, as long as the behaviors and the contract of the service do not change, users, namely service consumers, will not be aware of any difference.
We can think of the service interface as a standard plug socket for common indoor power supply, the service strategy as telling us that components used indoors do not have to be waterproof, and the service contract as an agreement to provide 24/7 220V power supply (in which, power supply at 180V to 250V 50 Hz is the quality requirement, 24/7 is the stability requirement, and the current supply <= 10A is the performance requirement.) This standard socket (service provider) can interact with and power any electrical appliance (consumer) that is compatible with the socket and conforms to the contract.
The service interface defines the style and details of the interaction, and the service implementation defines how a specific service provider or business function fulfills its role.
This architectural design, which is like a connection point/socket diagram, facilitates a more loosely coupled business function solutions.
The structure of service interfaces and implementations also has two important aspects, namely, the method of function execution and the information data related to execution. In other words, a service consists of a set of business service operations and the abstract business service data model of the corresponding operation inputs and outputs. The business service data model layer is the abstraction of business entities at the enterprise business layer or platform business layer, independent of the underlying data storage and implementation. This business data model is above and closely related to the subdomains that achieve consensus in a complete business line or on the platform level. In other words, a strict and clearly defined public model built on a consensus among subdomains is mainly used for the interactions of different domain services in platform business processes. Such a model serves as a unified business language at the platform level, so let's call it a Platform Business Data Model. The Platform Business Data Model usually includes a business glossary to ensure semantic consistency throughout the platform, a list of core entities in each domain of the platform, and an interaction diagram of the core entities in the platform.
The logic of interfaces and implementations consists of three important components:
1) Service Operation
A service operation declaration defines the input and output parameters of the operation.
2) Platform-Level Business Entity Model
The platform-level business entity model describes the structure and meaning of the input and output data in services. The differences between the information in service interfaces and the logical data in service implementations are crucial.
At the service interface level, the most important thing is that business services must exchange information to empower and perform business processes. Such information must be common to and consistent across all business services participating in the business process. In other words, the platform business entity model is standardized and shared by all services at the platform level. In addition, it must be defined and completed using the platform business semantics and ensure it can support all end-to-end services on the platform. A platform-level business entity model cannot be created overnight. It must be iterated and improved as the focuses of the platform shift.
However, internally, many services have different supersets of the information in their respective subdomains and may use different data formats for the information. Fortunately, we neither need to perceive nor reach a consensus on the relevant subdomain entity model among all associated services. Even if this is possible, it is not very realistic. On the contrary, the separation of service interfaces and service implementations enables convenient mapping and conversion between the platform-level business entity model and the domain model of the subdomain where the service is located.
3) The last component of the service interface logic is the service level agreement (SLA).
The SLA specifies two types of key indicators for the service: business indicators and technical indicators.
Technical Indicators: response time (RT), concurrent throughput, availability, and reliability.
Business Indicators: quality or completion of business functions, such as whether the inventory replenishment recommendation meets the turnover and stock-out KPIs of the business department (for example, reduce turnover by 10 days and lower the stock-out rate by 5%.)
To understand the service-oriented layered architecture, we must first develop a clear understanding of the TOGAF metamodel. The metamodel can reveal the core functions of business services and processes that connect business parties and the system platform. Therefore, it is imperative to grasp the significance of the metamodel in enterprise architecture. Below, there is a schematic diagram for reference purposes. This article will not get into details about TOGAF. If any readers desire more information on this issue, contact me, and I will try to write a separate article about it.
Generally, we build systems according to the business processes in different industries. For instance, our supply chain was initially incubated in the major appliance 3W business line, so a planning system that suited the needs of the merchants on our platform was developed based on the characteristics and business scenarios of the 3W industry. Then, the self-operated business line developed its planning system based on its business characteristics. Subsequently, home appliances, consumer electronics, overseas shopping, and other business lines also developed their respective business processes as they grew rapidly. The business process management (BPM) tool provides effective abstraction support for the development of diverse business systems. The applications built with the BPM tool are of a higher level, more abstract, and more efficient, but they are siloed and unable to provide overall support. This means it is difficult to rapidly cope with business challenges and achieve greater flexibility and agility for the business platform or system.
This is where business rules and decision-making functions can be organized as services, playing a greater role in SOA. SOA allows us to isolate business rules and business decision-making functions from specific business processes and turn them into business rule or decision-making services. Then, the services can be flexibly applied to different business processes and centrally managed and upgraded.
BPM and SOA are the perfect combinations to support enterprise architectures. BPM provides the ability to abstract and define business processes at a higher level and fulfill important monitoring and management functions associated with processes. Business services provide the core functions, decision-making capabilities, and information required to support business processes. SOA assembles the services to support and create flexible and agile end-to-end enterprise-level services. Without SOA, BPM may prove to be very useful in creating independent business applications, but it will be very difficult to expand such siloed applications to different business lines within an enterprise or on a platform. Without BPM, SOA can create reusable and highly consistent services but lacks the ability to rapidly use the services to create business processes and support end-to-end businesses. Also, it can't be used to establish competitive businesses that can agilely respond to external competitions.
The following section proposes a service-oriented layered architecture that includes the following layers:
The end-to-end business process consists of business operations that are executed in a sequence determined by certain business rules. A high-level business function usually spans multiple application domains or business lines. It is usually developed by an industry development team that operates under a clearly defined organizational structure, or by a virtual team with members from multiple teams who specialize in different domains. An interactive process for users to place orders in an e-commerce business or an inventory replenishment and transfer planning process in a supply chain business are both examples of end-to-end business processes.
A highly modularized business unit consists of various types of subdomain services that are assembled and orchestrated together, becoming an orchestration unit for business processes. Business services that are common across industries can be orchestrated and developed by the core domain development team, while business services common in specific industries can be orchestrated and developed by the corresponding industry development teams. An inventory replenishment approval service is an example of a platform business service.
Provided by functional subdomains, subdomain services are visible to the platform and can be used for assembly and orchestration of business services on the platform or as basic units for the orchestration of business processes of a higher level. Subdomain services are usually developed by platform subdomain development teams. Sales planning services and inventory replenishment recommendation and calculation services are examples of subdomain services.
The basic services that support various functional subdomain services are visible to the subdomain but not to the platform. They can be used for the orchestration of subdomain services.
Subdomain basic services are usually developed by platform subdomain development teams. Warehousing decision-making services, planning document services, and inventory planning services are examples of subdomain basic services.
Also known as fundamental business domain services, these services provide fundamental business services for the platform and fundamental business functions and data services for functional subdomain or platform business services. Merchant services, goods services, and inventory services are examples of fundamental subdomain services.
This layer provides infrastructure services shared by different layers, such as user management, permission management, and operation auditing. (See the figure below.)
We usually use the above-mentioned layered architecture to describe the platform architecture or the internal architecture of an enterprise. The hierarchical structure seems to be clear, but it is incomplete because the description of this service-oriented architecture is missing a core element of the platform system architecture: the information and information model layer. This is a critical element and often determines the success of the architecture.
To make the architecture complete and practical, we need to add the complete information abstraction (as an entity model or domain model):
The core documents used in the operation of the end-to-end business processes carry the information unit model that delivers core business value. These documents include sales orders, purchase orders, and inventory replenishment plan orders. This model is usually a core subset of platform public semantic models.
This model defines the platform-level business processes and business service interaction data. At the platform or enterprise level, it is the public semantic model for the interactive information used in end-to-end business processes. The model not only clearly defines the entities interacting through the platform business processes but also contains the complete business semantic entities required by business processes. It also clearly defines the boundaries and responsibilities of business semantic entities. The core document model is usually a subset of platform common semantic models. The platform public semantic model contains a subset of the external service entities for low-level subdomains. According to the end-to-end complete platform business semantics, it can be organically integrated from the core entity subset that platform functional subdomain models share with the platform, completely defined by the platform business model, or created bidirectionally through top-down and bottom-up merging. It should be noted that this model cannot be built overnight. Rather, it must be improved through countless iterations. Still, it is an essential element. Various architectural decisions and continuous evolution and improvement are achieved based on this model.
As domain models of the functional subdomains on the platform, these models are used to drive the design and development of application systems in each functional subdomain. Subdomain models need to maintain dynamism and stability. They use the anti-corrosion layer to isolate themselves from external domains and external services the model depends on. This prevents external services from contaminating core business semantics in the subdomain and keeps the business functions in the subdomain flexible and controllable. Subdomain models are only externally visible through the subsets of subdomain entities they serve externally.
These models are used in subdomain models to implement anti-corrosion dependence on external models.
This layer provides infrastructure information models that are common to different layers, such as user models and permission models.
The information architecture model framework is an important aspect not highly emphasized in the service-oriented layered architecture. The framework is important because the information architecture and service-oriented architecture are inseparable and form a complete whole. The information architecture model can be divided into five levels. The following section will introduce this hierarchical model from top to bottom.
This model defines the strategic direction and business purpose of an enterprise and therefore determines the direction and final result of any system platform development efforts within the enterprise. To be specific, it sets the tone for any system platform development efforts within the enterprise and influences the establishment of the medium and long-term goals and the final configuration of any system platform development projects.
Adopting the perspective of a business line owner, this model uses the business terms of the operating entity to describe the nature of the business model, including its overall structure, business processes, and organizational structure.
Adopting the perspective of business architecture, this model takes an information-based approach to abstract the business of one or more business lines. Level 1 describes the things or matters that are meaningful to the business of an enterprise. Level 2 defines these meaningful things more strictly and clearly, systematically specifies their connotations and extensions, and abstracts similarities according to the business content of different industries. This results in more efficient and flexible business descriptions and definitions.
Level 1 describes the business process as perceived by the business operation personnel. Level 2 also describes these business processes, but more importantly, it abstracts and describes the underlying business functions that these business processes should contain.
Similarly, Level 1 describes everything that matters to the business of an enterprise, and Level 2 describes the most fundamental content behind the information that the organization intends to manage. Level 1 describes samples or cases corresponding to the actual business of the basic entities defined by Level 2.
In short, Level 2 is the abstraction and synthesis of Level 1. To obtain this view, we must define the fundamental structure and content hidden in the main view of enterprise business operations through careful analysis, induction, and sometimes, deduction.
The public semantic model on Level 3 is closely aligned with the abstract business concept model on Level 2, but also adds semantics from the service-oriented perspective. The content described by the public semantic model on Level 3 is the business entities and information, whose semantics are consistent with the business services at the platform level. This is also a model that maintains the consistency of shared information at the platform level. The model at this level is the standard view model of all public service data based on the complete platform business semantics. It is used to describe the shared information exchanged through the service interfaces at the platform level. In short, the platform public semantic model defines the basic business service semantics at the business platform level. It also acts as the unified language for the interaction between business services on the platform, and between platform business processes and platform business services.
The domain model on Level 4 is defined as the domain model or entity model for a platform subdomain. It can abstract the core business functions of the corresponding subdomain. As the standard models for the subdomains on the platform, the domain models not only specify the semantics of services and service interfaces for each subdomain but also define the key entities in the service implementations of their corresponding subdomains. Overall, the domain models are the private models of each subdomain on the platform. Apart from their service semantics, the domain models are invisible to the outside. The service views of public information are a subset of the domain models.
The core of the domain model is used to expose the business service design and implementations of the subdomains on the platform and drive the design and implementation of service functions within the domain.
The domain model must remain dynamic and relatively stable unless the business in the domain changes in a fundamental way. The greatest enemy of domain model stability is external dependence. Therefore, the protection of the domain model against corrosion due to external dependence and the subsequent gradual erosion is the main purpose of the anti-corrosion layer. The subdomain anti-corrosion layer maintains the dynamic mapping between services with external dependencies and subdomain models, maintains the independence of domain models, and protects the domain models against harmful erosion.
The domain models here are quite similar to the common understanding of a domain model in so far as they abstract the business of each domain and design and implement solutions that drive technology design for each domain. As for the specific expression form of the models, both the ER diagram based on Aristotle's philosophy of material origin (from "material cause, formal cause, effective cause, final cause" to "entity + property + relationship") and the field-driven DDD mode based on Daoist philosophy (from "Man follows the law of earth, earth follows the law of heaven, heaven follows the law of Dao, and Dao follows the law of nature" to "entity + behavior") have their respective merits, so long as the essence of the business can be clearly expressed. I will address the differences between the two philosophies in a separate article.
This is the implementation model from the developers' perspective. It is the core object model and the cornerstone of system implementation.
What is a service? What is service-oriented layering? How can we design services and a service-oriented architecture? Here are the basic steps and solutions.
First, we need to understand the overall background of the service-oriented architecture. We must develop a thorough understanding of the business and its fundamental driving forces as well as business processes, business scenarios, and use cases. At the same time, if we are going to build a platform system, we must also understand the mission of the platform as set out in the enterprise strategy. What are the medium and long-term objectives of our platform? What is the end goal of the platform? The answers to these questions lay out the complete context of a service-oriented architecture. This context must be reflected in our business model, platform common semantic model, and domain models.
Then, we need to ask and answer the following questions:
The first six questions describe the overall architecture requirements (including business and platform requirements), while the remaining questions describe the overall context of the service-oriented architecture and the need for a service catalog library. Our services should not only be viewed individually but must reflect the complete business semantics and platform semantics from the perspective of the entire service set. The service set, or the service catalog library, must possess complete context semantics and identify the following:
The service catalog library must be designed to support two primary design-time objectives:
The first objective is to provide a mechanism that helps understand the overall context of the services for better service selection and more efficient service reuse. In particular, we need to understand what kind of responsibilities this service implements and how it is associated with other services.
The second objective is to provide a mechanism that identifies the responsibility boundaries of a specific service to guide the implementation of the service. This is a critical concept, especially when it comes to avoiding the duplication of service functions and data. Not only do we need to avoid duplicate construction, but we must also ensure consistency between service functions and data.
The services in the service catalog library are organized by service type and role. The service types are described in the preceding section on service-oriented layered architecture. The service roles include task service roles, entity service roles, and decision-making service roles. See the following section for more details.
One of the keys to the success of SOA is to create a set of services with complete business semantics so that services can be easily assembled and orchestrated to support different business processes and diversified business scenarios.
One frequently discussed topic is the loosely coupled services provided by functional domains. Loose coupling between services is particularly important because it reduces the dependencies between services, enables the reuse of services in different scenarios, and isolates the effects of changes. How can we achieve this objective?
Let's take a look at the most important characteristics of a service. What kind of business functions does the service provide? What kind of impact does the service have on data with business value? The answers to these two questions can help us easily identify two types of coupling that are particularly important in service interface designs:
Here is an example:
The transaction service coordinates all activities and then relies on other services to help complete the process. The transaction service depends on or is coupled with the user service, product service, inventory service, marketing service, order service, and payment service.
Why wasn't the transaction service designed to implement all these features?
This is because we want to reuse underlying capabilities in other high-level processes or services.
In addition, the transaction service is not tasked with providing the user service, product service, inventory service, marketing service, order service, and payment service. The transaction service only uses them, rather than performing them.
The user service is used to manage access to customer information. It is the only service responsible for providing, maintaining, and updating customer information. As such, the user service can be reused wherever access to customer data is required. Isolation or centralized access to customer information is more important than code usability because if there is only one path to access data, the data will always be consistent and Single Source Of Truth (SSOT) can be achieved. Therefore, although many services, including the transaction service, shopping cart, and historical orders need to access the user service, it is easy to manage these dependencies under a loosely coupled model.
The services created to perform user management, commodity management, inventory management, and marketing management can be used anywhere to perform consistent business functions.
The key message here is that a good service design not only focuses on reusability but also provides consistency, including function consistency and data consistency.
Next, we must determine the services we need and what we need them to do. To do this, we need to break down the relevant functions and isolate the relevant information.
In short, the basic principles of service design are:
Next, we must consider how to achieve these principles during the process of service-oriented design. To do this, we must answer the following questions:
Answers to these questions will help you determine:
When we design a service, one of the important considerations is the granularity of the service. However, there is no recognized standard to follow when it comes to determining the appropriate service granularity. So how can we make this decision? Despite the lack of standards, we still can use the following information to determine the right granularity for our service:
We can expect a variety of services in almost every complex environment or system platform. These services vary in type and granularity. See the section on service-oriented layering for more information or refer to the following service types listed below.
A business process usually extends across the entire enterprise or spans various business domains on the platform and is composed of underlying services.
Business services have the largest service granularity and provide highly abstract and assembled business functions for the platform or the enterprise. The functions and data of business services are closely integrated with the business semantics required by the business process. Data integration services provide the integrated data required by an end-to-end business process.
Subdomain services have a medium granularity. They provide business-related services for each business subdomain and are shared by other business services in the same subdomain. These services cannot be exposed outside the subdomain.
Subdomain basic services usually have the finest granularity. They provide lower-level services and are used to support the fundamental business functions in a subdomain.
Fundamental subdomain services also have a fine granularity. They support the complete implementation of the business functions provided by high-level business function services.
The infrastructure service layer provides the ability to create services of higher levels and medium granularity. It is independent of any business domain. Such services must be clearly separated from businesses, such as security authentication, permission management, and purely technical orchestration services.
In addition to the service granularity, scope of responsibilities, and service creation, another important consideration is the role a service plays in service assembly or process orchestration.
How can we distinguish between different service roles? We can follow the architecture principle of using focal points to achieve isolation. For instance, an important concept in building applications is the isolation of data and logic. This approach offers the possibility of achieving decoupling through various focal points. It also allows the use of multiple methods to implement the focal points at different places.
A case in point is the BPM tool that manages business processes separately. It relies on focal points to isolate business processes from other business logic. This allows it to put the processes on a specific level or in a specific environment for execution and management to rapidly create new process models and respond to business changes. At the same time, SOA has the ability to use business services as the basic components to create business processes. Another example of decoupling through focal points is the business rule management system (BRMS.) This system separates business rules or decision-making services from other application logic so that the services are executed and managed on a specific level and can be easily changed to support new business requirements. In this case, the business rules and decision-making services are exposed by the service-oriented institution to the rule and decision-making services to support the isolation of rules and decisions from business processes.
Generally, we adopt a larger granularity to define the three major service roles and construct the service levels:
Task services are usually used to implement a complete business function, which can be a basic business function, or a complicated business function, such as calculating the inventory replenishment quantity for a specific warehouse or a simple business validation to determine whether to replenish a certain product in a specific warehouse.
Task services can be used for a wide range of services, from independent subdomain basic services to larger platform business services. Services with a finer granularity are more likely to be used for common purposes, while services with a larger granularity are more likely to be reused. In most cases, business services are assigned to the task service role. Finer-granularity services usually support larger service assemblies and can be designed to support one or more specific processes. Therefore, they are less likely to be widely reused in cross-business processes. This makes sense because these services usually consist of other reusable services.
The services assigned to business roles are active services that deliver value through active behaviors.
The services that manage business entities are assigned to this role. Examples of business entities include users, categories, prices, inventories, and shopping carts. These entities mainly correspond to business information. Entities are usually of medium or large size and independent of any specific business process. They can be used as components of various business processes. The services assigned to the entity service role support the task services by adapting themselves or providing the required information to fulfill the tasks. Entity services are relatively more likely to be reused.
Rule/Decision-making services provide business decision-making functions by executing business rules. The automatic approval service for inventory replenishment is an example of this type of service.
These services are usually used to address complicated issues or support frequently changed business rules, such as complicated and variable approval rules.
These services are usually of fine or medium granularity and assembled into larger services. Rule/Decision-making services come in various types and can be used on various levels, including platform business services, subdomain services, and fundamental subdomain services. However, rule/decision-making services can also be used to support these types of services.
We assembled these service roles to provide flexible service capabilities and support the activities within business processes. There are some fundamental principles we can follow to assemble services to reduce dependency, restrict coupling, and maximize flexibility.
Now, with a collection of diversified processes, entities, and decision-making services, we can create different service assemblies. This allows us to consolidate the flexibility and variability of business rules and the modular design, flexibility, and reusability of SOA into the fundamental architecture design of business systems and platforms.
1. Long-Term Planning
A long-term plan is required to set service orientation objectives for the next 2 to 3 years. The plan must be as detailed as possible and systematically encourage collaboration and innovation according to the guiding principles and requirements explicitly stated in the long-term plan.
2. Piecemeal Objectives
Service orientation is not something that can be achieved with a single leap. Instead, we should begin by launching and promoting pilot projects, gather experience and lessons, and then expand the scope of pilot projects. This approach of starting small and growing gradually through step-by-step implementation will allow us to ensure that the domains comply with the systematic requirements established in the long-term plan and establish their respective service-oriented objectives based on their current situation and maturity. By establishing and achieving piecemeal objectives gradually, we can rapidly iterate the architecture and advance with agility.
3. Real Consensus
The fundamental purpose of reaching a consensus is to clarify the logic behind the objectives, architecture, design, and development of service orientation and make it comprehensible to everyone.
4. Be Pragmatic
The objectives and logic should be explained in the language of engineers, but be clear and plain. They should not be embellished with fashionable but vapid technical verbiage. Without systematic logic to support implementation, it is nearly impossible to achieve the true goal of service orientation.
5. Small Wins Lead to the Ultimate Victory
Building an SOA is not a rapid and all-out strike, but a protracted war. To be more specific, it is a massive, iterative, progressive, and systematic project. It takes endurance and preparedness to iterate the architecture, achieve piecemeal objectives at a quick pace, and continue gathering experience and lessons while adhering to systematic philosophy. In this process, small wins will lead to the ultimate victory.
6. Think Slow and Act Fast
One efficient way to get things done is to think slow and act fast. We are not necessarily short of people who can get things done, but we surely need people who can think independently and act in adherence to systematic philosophy.
The views expressed herein are for reference only and don't necessarily represent the official views of Alibaba Cloud.
How to Integrate Alibaba Cloud Log Service with Splunk Using the SLS Add-On
2,605 posts | 747 followers
FollowAlibaba Clouder - May 19, 2021
Bruno Delb - September 25, 2020
Alibaba Container Service - March 10, 2020
Lana - April 14, 2023
SeanLiu - April 17, 2020
Alibaba Cloud Community - December 20, 2021
2,605 posts | 747 followers
Follow
Microservices Engine (MSE)
MSE provides a fully managed registration and configuration center, and gateway and microservices governance capabilities.
Learn More
Architecture and Structure Design
Customized infrastructure to ensure high availability, scalability and high-performance
Learn More
ACK One
Provides a control plane to allow users to manage Kubernetes clusters that run based on different infrastructure resources
Learn More
SOFAStack™
A one-stop, cloud-native platform that allows financial enterprises to develop and maintain highly available applications that use a distributed architecture.
Learn MoreMore Posts by Alibaba Clouder
