In our past work, we often encountered the concept of "atomic service" or "atomized service". If there is no clear concept boundary, everyone's communication and discussion cannot be carried out on the same consensus, and everyone is not on the same channel. In terms of space, it is difficult to produce consistent progress because it is separated from different domain spaces. So, what exactly is an atomic service?
1. Discrimination and Analysis of Atomic Services
The term atomic service is composed of two units: "atom" and "service". So is the focus of semantics atomic or service? I personally think it's a service. However, the scope of the concept of service is still very large. The delivery boy is a service, and the haircut is also a service, and we are positioned in the software field, that is, we are discussing services based on software.
1.1 Atoms and Services
In the article "Discrimination between Componentization and Servitization", a service is defined as: "Any party can provide another party that is intangible in nature and does not result in any act or performance of ownership. Its production may be related to physical product, and may not be related to the physical product." In software, this is called "loose coupling". A software service is a coarse-grained, discoverable entity that exists as a single instance and interacts with applications and other services. The concept of a service differs from that of a component in that a service does not define any structural constraints, but rather an interface.
Atom is a concept of physics. In middle school physics class, we know that an atom is composed of an atomic nucleus and electrons outside the nucleus. Atoms and services belong to two different domains, so is the combination of atomic services just a metaphor or a real expression as an objective and unique software entity? The source of the ambiguity may lie in a combination of both.
1.2 Potential implications of atomic services
Personally, I think that the concept of atomic service is similar to that of microservice, both of which are ways to express the granularity of software services and how to realize the granular services. In microservices, it is often emphasized that the responsibility of the service should be as single as possible. The set of functional features of the business in the business system has not changed, but the composition method is composed of small-grained services, and more non-functional requirements, such as scalability and elasticity, are met through changes in the composition method. Atomic services emphasize indivisibility, describing services from the perspective of constraints.
That is to say, atomic service may have two meanings: granularity cannot be split and how to use such granular service to meet more demands. The former is understood from the dimension of space, while the latter is a process and result that can be understood from the dimension of time. Moreover, the latter generally use "atomized service" to express the process and the effect of service atomization, which is similar to micro-service. However, due to the profoundness of Chinese, people often use "atomic service" to unify the two meanings, and thus rely heavily on the context to determine which meaning "atomic service" refers to.
1.3 Atomic services and atomic operations
Atomic services are descriptions of services with minimal granularity. However, granularity is a relative concept and can only be precisely defined in specific scenarios. For example, a service can be considered coarse-grained if it implements all the functionality of a banking system. If it only supports credit balance checking, then it is considered fine-grained.
By analogy with atomic operations in programming languages, it may be possible to further understand the granularity of atomic services.
Atomic operation means "one or a series of operations that cannot be interrupted", which is a relatively familiar concept for us. From the user's point of view, atomic operations can be used to replace heavyweight lock synchronization, thereby improving program performance. From the perspective of the underlying implementation, atomic operations can be used to build various more heavyweight synchronization operations, such as locks or barriers. As far as the underlying implementation is concerned, for a single-processor single-core system, atomic operations can be realized as long as the operation instruction sequence is not interrupted. Generally, a spin lock is required to ensure that the operation instruction sequence will not be disturbed in the middle of execution. . For multi-processor or multi-core systems, the implementation of atomic operations needs to be guaranteed not only by spinlock, but also by other cores on the same processor or by other processors.
Analogous to atomic services, the indivisibility of atomic services actually emphasizes the transactional consistency of services, that is, the integrity of a service itself. Services should be at a level of abstraction that corresponds to real-world activities or identifiable business functions, and thus relatively coarse at the appropriate level of granularity for services and their methods. Atomic services typically support a single unique business concept or process, encompassing the software of an existing business concept, so it can be reused in a similar context.
2. Different meanings of atomic services in software systems
Because the atomic service itself has a metaphorical color, it also has different meanings in the software field and among different software systems.
2.1 Atomic service in web service
In the field of Web services, services are divided into two forms:
Atomic services: Services that cannot be further decomposed into finer grained services * Composite services: Services that are composed of multiple atomic services
Composite services are similar to other Web services in that they have WSDL service contracts and are invoked through SOAP messages. There are generally two ways to create synthetic services:
Create composite services through direct programming, such as publishing an EJB as a Web service that consumes other Web services.
Composite services are created by using Web service orchestration and WS-BPEL.
For the latter, developers typically use Web service orchestration products to define composite services, and a runtime engine (such as AcitveBPEL) that executes WS-BPEL process definitions.
2.2 Atomic services in microservices
In the microservice-related software architecture system, a series of operations at the smallest granularity in business can be abstracted into an atomic service. For example, the combination service that the user places an order can be split into——
User Deduction (User Account Microservice)
Deduct Inventory (Merchant Microservice)
Generate order (order center microservice) and wait
Analogous to atomic operations, since atomic operations are the smallest granularity operations that either succeed or fail, each atomic service in each microservice can only care about its own affairs, and don’t care about how other services are implemented or how internal failover works.
2.3 Atomic Services in SDV
In SDV (Software Defined Vehicle), the electrical architecture has changed from the original distributed architecture to the central domain + regional controller architecture. OEMs divide services into atomic services, composite services, and application services. Among them, the atomic service abstracts the smallest unit of service and a single execution entity (such as a sensor, an actuator), and provides a single-function service interface through the API, which can be called repeatedly. The most basic principle of atomic service division is that it cannot continue Break down.
The general design method for sensor atomic services in SDV is as follows:
For non-ECU sensors (voltage sensors, current sensors, pressure sensors, height sensors, etc.), convert the underlying software level signals into physical signals and provide APIs (such as voltage/current, etc.);
For ECU sensors (SAS sensors, ESC controllers), according to the analysis provided by the underlying services, convert them into physical signals and provide APIs (such as vehicle speed, rotation angle);
The health status information of the sensor itself is defined as an Event type, including various fault states. ,,
About the Atomic Service Design approach for SDV Actuators:
For non-ECU actuators, the external API interface is the bottom soft IO control command;
For the external API interface of the ECU actuator, it is the bus control input signal;
The service of each executor can be defined as an abstract service, and the service type is defined as a Field type;
The execution status of the actuator is defined as Event type, its status feedback and fault status.
2.4 Atomic services in Hongmeng system
In the Hongmeng system, the so-called "atomic service" is emphasized as "atomized service", its predecessor meta-service. The key features of meta-services are divisibility, integration and transferability.
Hongmeng describes the behavioral effects of atomized services from the perspectives of developers and users.
For developers, atomized services only need to be developed once, and can be used on various HarmonyOS terminals, reducing development costs. The atomic service is developed based on the HarmonyOS API and supports running on 1+8+N devices. The atomic service consists of one or more HAP packages, and one HAP package corresponds to one FA or one PA. Each FA or PA can operate independently to complete a specific function; one or more functions (corresponding to FA or PA) complete a specific convenient service.
For users, atomic service is a future-oriented service provision method provided by HarmonyOS. The atomic service has an independent entrance (users can directly trigger it by clicking, touching, scanning, etc.), and it is free of installation (no explicit installation is required, and it can be used after being installed in the background of the system program framework). User program form that provides one or more convenient services for users.
Based on the equipment of the Hongmeng system, Huawei has clearly defined the triggering method of the atomic service.
2.5 Relevant Standards of Atomic Services
Given that the conceptual scope of atomic services is not clear, the industry has not reached a unified consensus on atomic services. Currently, they are still in their own stages of evolution in their respective fields, and the industry has not yet formed relevant standards for atomic services.
However, in various fields, there is a tendency for the concept of atomic services to learn from each other. The Software Green Alliance once released a technical standard for atomic services. In this standard, atomic services are gathered in the meta-capability, and the English name is Atomic Ability. It is a program entity that can be executed independently to achieve a single function. Its bearer entity type can be a small program/quick application/native service. The atomic services defined by it have the following characteristics:
It can be started with the smallest set, with as little resource consumption as possible;
The AA between different applications is connected through the system, which better matches the user's scenario needs;
The rich access provided by the distribution platform makes the service provision more diverse and intelligent.
In the atomic service technical standard of the Software Green Alliance, atomic services are divided into the following two categories:
Web-based atomic services: small programs, quick applications, HTML5 applications
Native-based atomic service: It is a local atomic service based on the local (operating system) and written and run by native programs. The commonly used development languages are JAVA, C++, and Objective-C.
3. Atomic services in the field of design
In the field of design, the design of atomic services also represents different design concepts. At the earliest, the atomic design theory was inspired by web designer Brad Frost from the periodic table of chemical elements. All interfaces are composed of some basic elements, which are extended to the page dimension, that is, small pages form large pages.
Atomic design theory is defined as: an approach consisting of five distinct phases that work together to create more effective interface design systems in a more deliberate and layered manner. The five different stages are summarized as: atom, molecule, organization, template and page, as shown in the following table -
This "disintegrated and reorganized" interface design idea is widely used in the terminal interface design, realizing the responsive design of the mobile terminal. In all of these interface designs, when the underlying template is the same, the user interface often needs to change to reflect the dynamic nature of the content. These changes directly affect how the underlying molecules, organizations and templates are built, helping to create more resilient design systems.
Service design can use design thinking to integrate resources on the basis of services. Design thinking is just a methodology applied in service design. When the theory of atomic design is transferred from online (in the field of interface design) to online and offline (in the field of service design), new changes will appear in services. "Experience element" and "experience level" will change accordingly with their own attributes.
The advantages of atomic design theory in service design are reflected in systematic construction, standardized innovation and modular iteration.
4. One sentence summary
In view of the cognitive limitations and limited understanding of old coders, atomic services are considered to be an abstract concept that depends heavily on context. When it comes to the design, architecture, and engineering implementation of atomic services, it is necessary to clarify the conceptual space of atomic services first. Then determine the application field, perhaps to reflect the value of the atomic service.
【Associated reading】