Design method and calling method for service middleware of field-related application in embedded scene

Abstract

The invention provides a method for designing service middleware of field-related applications in an embedded scene, which comprises the following steps of: analyzing and abstracting characteristics of the field-related applications to construct a service middleware conceptual model; the service middleware conceptual model comprises a service node container entity serving as a core container, located at the top layer of a service process space and responsible for overall management of all service node entities in the service middleware; each service node entity comprises a service node service attribute manager for maintaining service attributes, a plurality of service consumers and service providers for realizing a request-response interaction mode, and a plurality of publishers and subscribers for supporting a publish-subscribe mode; the service middleware adopts a centralized architecture to realize service registration and discovery; and the service middleware adopts a multi-thread model design to deal with high-concurrency data processing. The method and the device are particularly suitable for distributed application scenes with specific requirements on domain-related business logic.

Description

Technical Field

[0001] This invention relates to the field of embedded systems, and in particular to a method for designing and calling service middleware for applications in embedded systems. Background Technology

[0002] As a key infrastructure for building robust, portable, and interoperable distributed systems, service middleware can effectively shield the specific platform environment and communication protocol details on which applications depend for execution, thereby allowing developers to devote all their energy to the implementation of business logic.

[0003] With the rapid development of computer technology, the service-oriented software engineering concept was first applied in the internet field. Since the beginning of the 21st century, the industry has proposed the concept of Web services and successively formulated three landmark technical standards: Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery and Integration Protocol (UDDI). These standards laid a solid foundation for the widespread application of Web service technology. To cope with the ever-increasing user traffic and product iteration needs, service-oriented architecture has gradually evolved towards a more refined and generalized direction, namely microservice architecture. This period saw the emergence of a series of excellent commercial implementations, such as Alibaba's Dubbo framework and Tencent's Tars platform. However, current mainstream service-oriented architecture products in the internet field generally suffer from overly cumbersome and complex implementations. Furthermore, there is controversy regarding the choice of application construction granularity in existing standards and products; excessively small granularity may introduce significant additional overhead. This makes it difficult for them to meet the requirements of hardware-restricted environments and diverse deployment methods.

[0004] In recent years, a series of excellent service-oriented architecture standards and products have emerged in the field of industrial control, such as the ROS / ROS2 framework in robotics and the SOME / IP protocol in the automotive field. These emerging standards and products have made significant progress in terms of the depth of abstraction of service interaction patterns, system flexibility, ease of use, and lightweight nature. However, these standards and implementation products generally fail to fully consider the domain-specific information of services. In specific fields (such as aviation), the domain-specific information of services is often a key decision indicator for service selection and optimization, and existing solutions are difficult to meet the requirements. Summary of the Invention

[0005] This application provides a service middleware design method for domain-related applications in embedded scenarios, enabling the construction of distributed collaborative systems in embedded scenarios. By providing ultra-lightweight runtime support with domain-related service description capabilities, hardware-aware adaptive capabilities, flexible business construction capabilities, and diverse communication mechanisms, it achieves efficient construction and optimization of distributed collaborative systems, and is particularly suitable for distributed application scenarios with specific requirements for domain-related business logic.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to a first aspect of the embodiments of this application, a service middleware design method for domain-related applications in embedded scenarios is provided, including: By analyzing and abstracting the application characteristics related to the domain, a service middleware conceptual model is constructed. The service middleware conceptual model includes a service node container entity as the core container, located at the top level of the service process space, which is responsible for the overall management of all service node entities in the service middleware. Each service node entity includes a service node business attribute manager for maintaining business attributes, several service consumers and service providers that implement the request-response interaction mode, and multiple publishers and subscribers that support the publish-subscribe mode. The service middleware adopts a centralized architecture to implement service registration and discovery. The centralized architecture is divided into an application layer, a service layer, a communication interface layer, and an operating system adaptation layer from top to bottom. Among them, the application layer provides standard interfaces to support application development; the service layer is used to provide service registration, service discovery, and service invocation functions; the communication interface layer provides data communication capabilities for the service layer; and the operating system adaptation layer adapts to the differences in interfaces of various operating systems. The service middleware adopts a multi-threaded model design to cope with high-concurrency data processing. The multi-threaded model achieves functional separation through a decoupled architecture of network threads and processing threads: the network thread is specifically responsible for the encapsulation and parsing of interactive data packets, the sending and receiving of network data, and other operations; the processing thread routes service request data to the corresponding interface and executes user business logic processing.

[0008] According to one embodiment of this application, the service node business attribute management includes a service node business capability attribute manager and a service node business status attribute manager; wherein, the service node business capability attribute manager is used to maintain attribute information related to business functions; the service node business status attribute manager is used to track and record attribute information related to business operation status; all attribute information is represented and stored using a key-value pair structure.

[0009] According to one embodiment of this application, the service consumer and service provider adopt a request-response communication model, specifically including: Service providers register their service information in the service registry's service registration list; Service consumers retrieve available service instances from the service registration list by specifying the service name, and use the built-in service selection algorithm to filter out the best matching service node from multiple candidate services. Finally, they establish a direct communication link with the service node to complete request processing and response return.

[0010] According to one embodiment of this application, the publisher and subscriber adopt a publish-subscribe communication pattern, specifically including: Subscribers specify the topics they wish to follow before subscribing, and the system records the subscription information. When sending data, the publisher establishes a communication connection with all registered subscribers based on the preset topic identifier.

[0011] According to one embodiment of this application, the service layer includes at least a service registration module, a service invocation module, a topic data publishing module, a service provider interface routing module, and a subscriber interface routing module; wherein... The service registration module is used to complete the data registration and dynamic update of various logical entities, including service nodes, service node business attributes, service consumers, service providers, publishers and subscribers; The service invocation module is used to process invocations from service consumers to service providers; The topic data publishing module is used to process the topic data publishing operations of the publisher; The service provider interface routing module is used to receive request data from service consumers; The subscriber interface routing module is used to receive topic data sent by the publisher.

[0012] According to one embodiment of this application, the service middleware adopts a parallel architecture of multiple network threads and multiple processing threads, wherein each network thread includes: Service request queue: When a service consumer / subscriber in the calling thread initiates a call, its service request is inserted into the service request queue of the network thread associated with it. Service request sent queue: used to cache incomplete requests that have been sent to the network or are waiting to be sent to the network and are stuck in the network data sending cache queue; Network data transmission buffer queue: used for temporary storage of data that has not yet been successfully transmitted to the network; Both the service request sent queue and the service request pending queue adopt a time priority queuing mechanism. Each processing thread includes a service request queue for storing pending requests.

[0013] According to one embodiment of this application, the service middleware adopts two modes in the service call request sending and processing method: serial and parallel. In the serial mode, each request is processed serially in strict order of initiation, and the next request must wait for the response of the previous request before it can be sent. In the parallel mode, multiple requests are allowed to be executed simultaneously.

[0014] According to one embodiment of this application, the service middleware adopts an efficient thread communication mechanism to realize the collaboration between the network thread and the processing thread; after receiving the service request initiated by the client, the network thread of the server distributes the request to the service request waiting queue maintained by the corresponding processing thread according to the fair allocation principle of load balancing; the processing thread extracts the service request from the corresponding service request waiting queue, performs routing processing on the service provider interface, and finally returns the processing result to the client through the network thread.

[0015] According to one embodiment of this application, the service request waiting queue and the service request waiting queue are equipped with flow control thresholds for bidirectional flow limiting between the client and the server.

[0016] According to a second aspect of the embodiments of this application, a service middleware service invocation method is provided, which is a service middleware implementation based on the service middleware design method for embedded scenarios and domain-related applications described in the first aspect, specifically including: Service call initiation: Service consumers residing in the calling thread trigger service call requests through a unified interface specification; Connection status detection and service discovery: First, the connection status between the current service consumer and the target service provider is detected. If they are not connected, service discovery is performed in the registry based on the service name. The best service node is selected from the service list through a domain-customized load balancing algorithm, and then a connection is established with the service node. Request delivery: Delivers the service call request to the service request queue maintained by the associated network thread; Connection ready check: After the client waits for the connection to be ready, it extracts the first element from the service request queue and processes it. Data encapsulation and transmission: The service call request is encapsulated into standardized network data packets according to the protocol specifications and written into the bidirectional network data sending buffer queue of the network thread; when the network sending buffer is detected to be writable, the data to be sent in the buffer queue is written into the network sending buffer in batches, and the request is recorded in the service request sent queue at the same time. Server-side processing: After receiving a service call request from the client, the server's network thread distributes the service call request to the service request queue maintained by the corresponding processing thread according to a preset allocation strategy. Response processing and feedback: The processing thread retrieves requests from the service request queue and processes them; after completing the business logic processing, it feeds back the processing results to the service consumer through the network thread in accordance with the agreed protocol specifications; Response notification: After receiving the response data packet from the service provider, the network thread of the service consumer removes the corresponding request record from the service request sent queue and notifies the caller of the processing result through an asynchronous callback mechanism or a blocking queue.

[0017] Compared with existing technologies, the beneficial effects of adopting the above technical solution are as follows: 1. Effectively meets the needs of applications with limited hardware resources. The service middleware adopts a modular design, implementing only necessary functions (such as service registration and discovery, service invocation, data publishing, interface routing, protocol processing, etc.), with extremely low overhead. Through reasonable configuration, network threads and business processing threads can be dynamically allocated, and the number of worker threads can be flexibly set, ensuring stable operation even in a single-core processor environment.

[0018] 2. Enables efficient and flexible application development models. For complex distributed systems, the service middleware supports flexible service splitting strategies: large applications can be divided into several independent service node instances, or multiple service node instances can be created within a single process, fully meeting different business scenarios and deployment requirements.

[0019] 3. Intelligent service selection based on domain knowledge. The service middleware deeply integrates domain-driven design principles, maintaining complete metadata information (including basic attributes, capability characteristics, and real-time status) carrying domain-related information in each service node. When a service consumer initiates a call request, it can filter the optimal service from the list of available services based on this metadata information, achieving precise service scheduling.

[0020] 4. Efficiently handles large-scale concurrent requests. Employing the classic Reactor thread model, it decouples network communication threads from business processing threads and supports flexible configuration of the thread pool size, combined with parallel request sending strategies. This design ensures efficient data transmission while significantly improving service request processing capabilities, fully meeting the performance requirements of high-concurrency scenarios.

[0021] 5. Achieve efficient utilization of hardware resources. The service middleware can dynamically adjust runtime resources based on the underlying hardware configuration (such as the number of CPU cores). Through an intelligent thread scheduling mechanism, the performance of the software system is linearly positively correlated with hardware capabilities, fully unleashing the computing potential of multi-core processors.

[0022] 6. Provides a complete system protection mechanism. The service middleware can implement rate limiting control on both the client and server sides (by setting reasonable threshold levels), effectively preventing system unavailability caused by sudden traffic surges or resource overload, and ensuring the stability and reliability of the overall system. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0024] Figure 1 This is a schematic diagram of the service middleware conceptual model according to an embodiment of this application.

[0025] Figure 2 This is a schematic diagram of the service middleware communication mode in an embodiment of this application.

[0026] Figure 3 This is a diagram showing the components of the service middleware in an embodiment of this application.

[0027] Figure 4 This is a schematic diagram of the service middleware thread model in an embodiment of this application.

[0028] Figure 5 This is a schematic diagram illustrating the service request sending and processing principle of the service middleware in this application embodiment.

[0029] Figure 6 This is a complete flowchart of the service invocation process in an embodiment of this application.

[0030] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0032] The term "comprising" and any variations thereof in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive protection. For example, a process, method, system, product, or apparatus that comprises a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0033] In response to the problems in the background technology, the inventors believe that service middleware for embedded application scenarios should possess the following five core characteristics: (1) Domain-related information representation: The middleware not only needs to provide standardized service discovery information (such as basic metadata such as service name and service address), but also needs to integrate domain-specific information closely related to specific business scenarios to improve the accuracy and efficiency of service discovery and matching, and provide richer semantic support for upper-layer business logic; (2) Extremely lightweight: Middleware needs to strictly control resource consumption in order to achieve extremely low CPU usage, memory usage and network bandwidth overhead; (3) Adaptive capability: The system must have dynamic perception and response capabilities, and be able to automatically adjust the performance parameters of the middleware according to changes in hardware resources in the runtime environment; (4) Flexible business construction support: The middleware needs to provide a highly configurable and extensible functional framework so that it can support flexible service granularity splitting according to the needs of different application scenarios; (5) Diverse communication modes: Middleware needs to provide flexible communication mechanisms to adapt to the interaction needs of different application scenarios.

[0034] Based on this, this application proposes a service middleware design method for domain-related applications in embedded scenarios. This method constructs a complete service middleware conceptual model by analyzing and abstracting the characteristics of domain-related applications. Within this model framework, complex distributed applications are divided into multiple sub-applications according to functional modules, and the core logical unit of each sub-application is defined as a "service node". Each service node consists of the following key components: a business attribute manager for representing domain knowledge, service consumer and service provider entities that implement the request-response interaction mode, and logical entities such as publishers and subscribers that support the publish-subscribe mode.

[0035] Regarding service scheduling and selection mechanisms, an intelligent service selector based on domain knowledge is adopted. By analyzing application scenario characteristics and business attributes, it can accurately match and select the optimal service from the list of available services, significantly outperforming traditional load balancing strategies. The service registration and discovery process is implemented using a centralized model, which eliminates the network broadcast overhead problem present in the decentralized model, while ensuring the reliability of the service discovery process and the simplicity of the protocol implementation.

[0036] In terms of performance optimization under high concurrency scenarios, the Reactor thread model is adopted, which effectively improves the system's responsiveness by decoupling network threads from processing threads and combining them with a parallel request sending strategy. To fully leverage the computing potential of multi-core CPU architecture, the service middleware adopts a hybrid architecture design with multiple network threads and multiple processing threads, and dynamically adjusts the thread pool size according to the actual hardware configuration to ensure that software performance can be significantly improved with hardware upgrades.

[0037] In terms of system protection, by setting up flow level control mechanisms on both the client and server sides, dual flow limiting protection is achieved, effectively preventing performance degradation caused by system overload.

[0038] The following is combined Figures 1-6 The service middleware design method for embedded domain-related applications proposed in the embodiments of this application will be described in detail.

[0039] Please refer to Figure 1 In this embodiment, key entities of the service middleware for applications in embedded scenarios are modeled to form a conceptual model of the service middleware. In this conceptual model, the service node container entity, as the core container, is located at the top level of the service process space and is responsible for the overall management of all service node entities in the service middleware. When dealing with complex applications, the service node container entity may contain multiple service node entities, which are divided according to functional modules. Each service node entity consists of the following components: a service node business attribute manager for maintaining business attributes, several service consumer and service provider entities that implement the request-response interaction mode, and multiple publisher and subscriber entities that support the publish-subscribe mode.

[0040] The service node business attribute manager is a key component in establishing domain knowledge. In this embodiment, the service node business attribute manager includes a service node business capability attribute manager and a service node business status attribute manager. The service node business capability attribute manager specifically maintains attribute information related to business functions, such as the detection range of a radar application; while the service node business status attribute manager is responsible for tracking and recording attribute information related to the business's operational status, such as the operating mode of a photoelectric sensor.

[0041] In this embodiment, by deeply integrating the domain-driven design concept, complete metadata information carrying domain-related information (including basic attributes, capability characteristics, and real-time status) is maintained in each service node. When a service consumer initiates a call request, the optimal service can be selected from the list of available services based on this metadata information, achieving precise service scheduling.

[0042] It should be further noted that in this embodiment, a key-value pair structure is used to represent and store these attribute information. The attribute key describes the business attribute name and is of character data type; the attribute value represents the specific business attribute value. Multiple data types can be configured according to actual needs, and it has good scalability. This key-value pair design not only facilitates attribute management but also provides strong support for the system's flexibility and maintainability.

[0043] Please refer to Figure 2 It illustrates the two communication modes supported by the service middleware in this embodiment: the request-response mode based on the client-server architecture, and the data-centric publish-subscribe mode. These two modes can meet the needs of different application scenarios.

[0044] Please continue to refer to this. Figure 2 The request-response model is suitable for scenarios requiring immediate confirmation and synchronous processing, such as system control, and is primarily implemented between service consumers and service providers. Specifically, the service provider's first step is to register its service information in the service registry's service list, thereby enabling service disclosure and discovery. Subsequently, the service consumer retrieves available service instances from the service registry by specifying the service name, and uses a built-in service selection algorithm to filter out the optimal matching service node from multiple candidate services. Finally, it establishes a direct communication link with that service node to complete request processing and response return.

[0045] The publish-subscribe pattern is designed for scenarios such as real-time data distribution and event-driven notifications. Participants in this pattern include publishers and subscribers, whose interaction is established based on topic identifiers. Specifically, subscribers must explicitly specify the topic identifiers they wish to follow before subscribing, and the system records this subscription information. When a publisher sends data, it establishes communication connections with all registered subscribers based on the preset topic identifiers, thereby achieving accurate data distribution and efficient interaction. This pattern is particularly suitable for real-time data processing applications requiring low latency and high concurrency.

[0046] Please refer to Figure 3 In this embodiment, the service middleware adopts a centralized architecture to implement service registration and discovery. Compared with a decentralized architecture, the centralized architecture does not require broadcast traffic, which can ensure network resource optimization, provide a stable and reliable discovery process, and implement a simple and efficient protocol.

[0047] Specifically, this centralized architecture is divided into an application layer, a service layer, a communication interface layer, and an operating system adaptation layer from top to bottom. The application layer provides standard interfaces to support application development; the service layer focuses on core service-oriented functions, including service registration, service discovery, and service invocation; the communication interface layer provides data communication capabilities for the service layer; and the operating system adaptation layer adapts to the differences in interfaces of various operating systems, providing the service layer with a unified and compatible set of operating system interfaces.

[0048] Please continue to refer to this. Figure 3 In this embodiment, the service layer of the service middleware includes at least a service registration module, a service invocation module, a topic data publishing module, a service provider interface routing module, and a subscriber interface routing module. The specific functions and implementation processes of each module are as follows: (1) Service Registration Module: Responsible for completing the data registration and dynamic updates of various logical entities, covering service nodes, service node business attributes, service consumers, service providers, publishers and subscribers, etc. Its operation process includes first storing the service registration information in the local service data management module, and then writing the relevant data to the service registration center through the service registration center client module to ensure data consistency and availability.

[0049] (2) Service Invocation Module: This module is responsible for processing service consumer invocations to service providers. When a service consumer initiates an invocation for the first time, this module obtains a list of available service information from the service registry through the service discovery mechanism. Subsequently, based on a preset selection strategy, the service selector selects the best-matching service node from the list of available services. After establishing a communication connection, the service consumer sends a request to the service provider and waits for a response, completing a full remote invocation process.

[0050] (3) Topic Data Publishing Module: Responsible for handling the topic data publishing operations of publishers. Before formal data publishing, a data transmission connection needs to be established with subscribers. The connection establishment process includes two main stages: First stage: When a publisher registers with the registry center, the system automatically queries existing publishers with the same name based on the topic name and immediately establishes a connection for them. Second stage: The publisher continuously monitors the registry center's dynamics and senses the online and offline status of subscribers under the same topic in real time. When a new subscriber is detected to be online, the system automatically adds the corresponding item to the publisher's connection list and completes the connection; conversely, when a subscriber goes offline, the relevant connection items are promptly cleaned up. During the data publishing process, the publisher first writes the data to be sent into the publisher queue, and the data sending processing module is responsible for extracting and traversing all currently valid connections, transmitting the data sequentially to each subscriber.

[0051] (4) Service Provider Interface Routing Module: The main responsibility of this module is to receive request data from service consumers. Based on the service node name and target service provider information in the request content, this module accurately routes the request to the corresponding service implementation function for processing. After the service implementation function completes the request processing and generates a response, the module encapsulates the response data into a standard format service response packet and returns it to the service consumer through the network receiving module.

[0052] (5) Subscriber Interface Routing Module: This module is responsible for receiving topic data sent by the publisher. Based on the service node name and target subscriber information in the data, this module accurately routes the data to the corresponding subscriber implementation function, completing data distribution and processing.

[0053] Please refer to Figure 4 In this embodiment, the service middleware adopts a multi-threaded model design to handle high-concurrency data processing. This multi-threaded model achieves functional separation through a decoupled architecture between network threads and processing threads: the network thread is specifically responsible for the encapsulation and parsing of interactive data packets, and the sending and receiving of network data; the processing thread routes service request data to the corresponding interface and executes user business logic processing.

[0054] In practical applications, to flexibly respond to different load scenarios, the system supports dynamic adjustment of thread roles: when the amount of network data is small and the business processing is simple, a thread merging mechanism can be adopted, that is, the network thread directly takes on the function of the processing thread, avoiding the resource consumption caused by maintaining a separate processing thread.

[0055] Furthermore, to maximize the computing power of multi-core CPUs, the service middleware adopts a parallel architecture design with multiple network threads and multiple processing threads. In addition, by keeping the number of threads linearly consistent with the number of CPU cores, the system ensures that software performance can significantly improve with hardware upgrades, thereby achieving superior scalability and resource utilization.

[0056] In this embodiment, the parallel architecture mainly includes a service request waiting queue, a service request sent queue, and a network data sending cache queue in the network thread; and a service request waiting queue in the processing thread. Specifically, the service request waiting queue stores initiated service requests; the service request sent queue caches incomplete requests that have been sent to the network or are waiting to be sent to the network and are currently in the network data sending cache queue; the network data sending cache queue temporarily stores data that has not yet been successfully sent to the network; and the service request waiting queue stores requests to be processed.

[0057] Please continue to refer to this. Figure 4Taking the request-response pattern as an example, this paper elaborates on the working principle of the service middleware thread model (the working mechanism of the publish-subscribe pattern is similar and will not be elaborated here): In actual operation, the calling thread and the network thread communicate through an efficient service request queue. Specifically, when a service consumer in the calling thread initiates a call, its service request is inserted into the service request queue of its associated network thread. This thread association is based on a fair allocation principle to ensure balanced load distribution.

[0058] In addition to the service request queue, the network thread also maintains two key queues: the service request sent queue and the network data sending buffer queue. Among them: The service request sent queue is used to cache incomplete requests that have been sent to the network or are waiting to be sent to the network and are currently in the network data sending buffer queue. This queue primarily performs two core functions: first, it temporarily stores the response data returned by the server for sent requests, ensuring that each service call request accurately receives the corresponding processing result through unique identifiers and an efficient mapping mechanism, achieving a strict one-to-one correspondence between requests and responses; second, it implements a timeout handling mechanism for sent requests. Furthermore, to prevent long waiting times in the service request sent queue due to network thread blocking, the system also implements a timeout handling mechanism for client requests in the service request sent queue.

[0059] Both the sent service request queue and the pending service request queue employ a time-priority queuing mechanism, implemented using an efficient data structure based on a priority heap. This design ensures that the system can process the earliest timed-out service request within a predetermined time window, effectively avoiding service interruptions or retries due to timeouts, thereby improving the overall system's real-time performance and stability. This mechanism reflects the system architecture's deep consideration for efficient service scheduling and reliable communication.

[0060] The network data transmission buffer queue is used to temporarily store data that has not yet been successfully sent to the network, which usually occurs when the network transmission buffer is full. This design effectively solves the data transmission blocking problem caused by network bandwidth limitations.

[0061] Meanwhile, the service middleware employs an efficient thread communication mechanism to achieve collaboration between network threads and processing threads. Specifically, after receiving a service request from a client, the server-side network thread distributes the request to the service request queue maintained by the corresponding processing thread according to the principle of fair allocation of load balancing. Subsequently, the processing thread retrieves the service request from this queue, performs routing processing on it using the Service Provider Interface (SPI), and finally returns the processing result to the client through the network thread. When the system is under high load, to prevent resource exhaustion, reasonable flow control thresholds can be set in both the service request sending queue and the service request processing queue to achieve bidirectional rate limiting between the client and server. This mechanism effectively protects the system from overload while ensuring service quality.

[0062] Please refer to Figure 5 This embodiment provides two service call request sending and processing methods: serial and parallel. In serial mode, each request is processed strictly in the order it was initiated, and the next request must wait for the response of the previous request before it can be sent. This method has low processing efficiency. Parallel mode, on the other hand, allows multiple requests to be executed simultaneously, thereby improving overall processing efficiency. It is worth noting that although parallel processing can significantly improve throughput, the degree of parallelism needs to be set reasonably to avoid network resource overload due to too many concurrent requests.

[0063] For further details, please refer to... Figure 6 This embodiment also provides a service middleware service invocation method, which is a service middleware implementation designed based on the aforementioned service middleware design method for domain-related applications in embedded scenarios, specifically including: S1: Service call initiation. Service consumers residing in the calling thread trigger service call requests through a unified interface specification.

[0064] S2: Connection Status Detection and Service Discovery. The system first checks the connection status between the current service consumer and the target service provider. If they are not connected, the system will perform service discovery in the registry based on the service name, pull a list of available servers, and select the best service node from the list using a domain-customized load balancing algorithm to ensure optimized network latency and resource utilization. Subsequently, the system will establish a secure connection with that service node.

[0065] S3: Request delivery. Service call requests are securely delivered to the service request queue (priority queue structure) maintained by the associated network thread to ensure efficient concurrent processing capabilities.

[0066] S4: Connection Readiness Check. After the client waits for the connection to be ready, it retrieves the first element from the service request queue and processes it.

[0067] S5: Data Encapsulation and Transmission. Service call requests are encapsulated into standardized network data packets according to protocol specifications. These packets are then written to the bidirectional network data transmission buffer queue of the network thread. When the network transmission buffer is detected to be writable, the system automatically writes the data to be sent from the buffer queue into the network transmission buffer in batches. Simultaneously, the request is recorded in the service request sent queue (priority queue structure) to ensure the reliability and traceability of the operation.

[0068] S6: Server-side processing. After receiving a service call request from a client, the server-side network thread distributes the request to the service request queue maintained by the corresponding business processing thread according to the allocation strategy (such as weighted round-robin, random, or IP hash) to achieve load balancing.

[0069] S7: Response Processing and Feedback. The processing thread retrieves requests from the service request queue and processes them. After completing the business logic processing, the server sends the processing result back to the service consumer via a network thread, according to the agreed protocol specifications.

[0070] S8: Response Notification. After receiving the response data packet from the service provider, the service consumer's network thread removes the corresponding request record from the service request sent queue and notifies the caller of the processing result through an asynchronous callback mechanism or a blocking queue, thus completing the closed loop of the entire service call process.

[0071] Based on the same technical concept, embodiments of this application also provide an electronic device that can implement the service middleware design method or invocation method flow for embedded domain-related applications provided in the above embodiments of the present invention. In one embodiment, the electronic device can be a server, a terminal device, or other electronic devices. Figure 7 As shown, the electronic device may include: At least one processor and a memory connected to the at least one processor. In this embodiment of the invention, the specific connection medium between the processor and the memory is not limited. Figure 7 The example used is the connection between the processor and memory via a bus. The bus... Figure 7 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. Buses can be categorized into address buses, data buses, control buses, etc., but for ease of representation, [the specific bus type is not shown here]. Figure 7 The processor is represented by a single thick line, but this does not imply that there is only one bus or one type of bus. Alternatively, a processor can also be called a controller; there are no restrictions on the name.

[0072] In this embodiment of the invention, the memory stores instructions executable by at least one processor. By executing the instructions stored in the memory, the at least one processor can execute the service middleware design method or invocation method for domain-related applications in an embedded scenario, as described above. The processor can implement... Figure 7 The functions of each module in the device shown.

[0073] The processor is the control center of the device. It can connect to various parts of the control equipment through various interfaces and lines. By running or executing instructions stored in memory and calling data stored in memory, it can monitor the various functions and data processing of the device as a whole.

[0074] In an alternative design, the processor may include one or more processing units. The processor may integrate an application processor and a modem processor, wherein the application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may also not be integrated into the processor. In some embodiments, the processor and memory may be implemented on the same chip; in some embodiments, they may also be implemented separately on separate chips.

[0075] The processor can be a general-purpose processor, such as a CPU, digital signal processor, application-specific integrated circuit, field-programmable array, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the service middleware design method or invocation method for a domain-related application in an embedded scenario disclosed in the embodiments of this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0076] Memory, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory can include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. In embodiments of the present invention, memory can also be a circuit or any other device capable of implementing storage functions, used to store program instructions and / or data.

[0077] By designing and programming the processor, the code corresponding to the service middleware design method or calling method for domain-related applications in embedded scenarios described in the foregoing embodiments can be embedded into the chip, thereby enabling the chip to execute the steps of the methods in the above embodiments during runtime. How to design and program the processor is a technique well known to those skilled in the art, and will not be elaborated here.

[0078] Based on the same inventive concept, embodiments of the present invention also provide a storage medium storing computer instructions that, when executed on a computer, cause the computer to execute a service middleware design method or invocation method for a domain-related application in an embedded scenario, as described above.

[0079] In some alternative embodiments, the present invention also provides a service middleware design method or invocation method for domain-related applications in embedded scenarios, which can also be implemented as a program product including program code. When the program product is run on a device, the program code is used to cause the control device to perform the steps in the service middleware design method or invocation method for domain-related applications in embedded scenarios according to various exemplary embodiments of the present invention as described in this specification.

[0080] It should be noted that although several units or sub-units of the apparatus have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the invention, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units. Furthermore, although the operation of the method of the invention is described in a specific order in the drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0081] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0082] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a server, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0083] Program code for performing the operations of this invention can be written using any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0084] In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0085] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0086] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A service middleware design method for domain-related applications in an embedded scenario, characterized in that, Comprise: By analyzing and abstracting the application features related to the field, a service middleware conceptual model is constructed; the service middleware conceptual model includes a service node container entity as a core container, located at the top layer of the service process space, responsible for overall management of all service node entities in the service middleware, each service node entity includes a service node business attribute manager for maintaining business attributes, a number of service consumers and service providers for implementing a request-response interaction mode, and a plurality of publishers and subscribers supporting a publish-subscribe mode; The service middleware adopts a centralized architecture to realize service registration and discovery, which is divided into an application layer, a service layer, a communication interface layer, and an operating system adaptation layer from top to bottom; wherein the application layer provides a standard interface to support application development; the service layer is used to provide service registration, service discovery, and service invocation functions; the communication interface layer provides data communication capabilities for the service layer; the operating system adaptation layer adapts to the differences of various operating system interfaces; The service middleware adopts a multi-threaded model to design to cope with high concurrency data processing; the multi-threaded model realizes functional separation through the decoupling architecture of network threads and processing threads: wherein the network thread is responsible for the encapsulation and analysis of interactive data packets, and the sending and receiving operations of network data; the processing thread routes the service request data to the corresponding interface and executes user business logic processing.

2. The service middleware design method for embedded field-scenario dependent applications according to claim 1, characterized in that, The service node business attribute management includes a service node business capability attribute manager and a service node business state attribute manager; wherein the service node business capability attribute manager is used to maintain attribute information related to business functions; the service node business state attribute manager is used to track and record attribute information related to business running state; the attribute information is represented and stored through key-value pair structure.

3. The service middleware design method for embedded field-scenario dependent applications according to claim 1, characterized in that, The service consumer and the service provider adopt a request-response communication mode, specifically including: The service provider registers its service information in the service registration list of the service registration center; The service consumer retrieves available service instances in the service registration list by specifying the service name, and uses the built-in service selection algorithm to select the optimal matching service node from multiple candidate services, and finally establishes a direct communication link with the service node to complete request processing and response return.

4. The service middleware design method for embedded field-scenario dependent applications according to claim 1, characterized in that, The publisher and the subscriber adopt a publish-subscribe communication mode, specifically including: The subscriber specifies the topic identifier of interest before subscribing, and the system records the subscription information; The publisher establishes a communication connection with all registered corresponding subscribers according to the preset topic identifier when sending data.

5. The service middleware design method for embedded context-aware domain-dependent applications according to claim 1, wherein, The service layer at least includes a service registration module, a service invocation module, a topic data publishing module, a service provider interface routing module, and a subscriber interface routing module; wherein, The service registration module is used to complete the data registration and dynamic update of various logical entities, including service nodes, service node business attributes, service consumers, service providers, publishers, and subscribers; The service invocation module is used to complete the invocation processing of the service consumer to the service provider; The subject data publishing module is used for processing a subject data publishing operation of a publisher; The service provider interface routing module is used for receiving request data from a service consumer; The subscriber interface routing module is used for receiving subject data sent by a publisher.

6. The service middleware design method for embedded context-aware domain-dependent applications according to claim 1, wherein, The service middleware adopts a parallel architecture of multiple network threads and multiple processing threads, each network thread comprising: a service request to-be-sent queue: when a service consumer / subscriber in a main thread initiates a call, the service request of the service consumer / subscriber is inserted into the service request to-be-sent queue of the network thread associated with the service consumer / subscriber; a service request sent queue: used for caching an unfinished request that has been sent to a network or is waiting to be sent to the network and lingers in a network data sending cache queue; a network data sending cache queue: used for temporarily storing data that has not been successfully sent to the network; The service request to-be-sent queue and the service request sent queue both adopt a time priority queuing mechanism; Each processing thread comprises a service request to-be-processed queue used for storing a request to be processed.

7. The service middleware design method for embedded context-aware domain-dependent applications according to claim 1, wherein, The service middleware adopts two modes of serial and parallel in service call request sending processing; in the serial mode, each request is processed in series according to the initiation order, and the next request can be sent only after the response of the previous request; in the parallel mode, multiple requests are allowed to be executed simultaneously.

8. The service middleware design method for embedded context-aware domain-dependent applications according to claim 1, wherein, The service middleware adopts an efficient thread communication mechanism to realize cooperation between network threads and processing threads; after a network thread of the service end receives a service request initiated by a client, the request is distributed to the service request to-be-processed queue maintained by the corresponding processing thread according to the fair allocation principle of load balancing; The processing thread extracts the service request from the corresponding service request to-be-processed queue, performs routing processing of the service provider interface, and finally returns the processing result to the client through the network thread.

9. The service middleware design method for embedded field-scenario dependent applications according to claim 6, characterized in that, Flow control thresholds are set in the service request to-be-sent queue and the service request to-be-processed queue, which are used for bidirectional flow control of the client and the service end.

10. A method of service invocation for a service middleware, characterized by, The service middleware implementation based on the service middleware design method of any one of claims 1-9 in the embedded scenario, specifically comprising: service call initiation: a service consumer residing in a main thread triggers a service call request through a unified interface specification; connection state detection and service discovery: first, the connection state of the current service consumer and the target service provider is detected, if in an unconnected state, service discovery is performed in the registration center based on the service name, the best service node is selected from the service list based on a domain customized load balancing algorithm, and then the connection with the service node is established; request delivery: the service call request is delivered to the service request to-be-sent queue maintained by the network thread associated with the service call request; connection readiness check: after the client waits for the connection to be ready, the head element in the service request to-be-sent queue is extracted for processing; Data packaging and transmission: The service call request is packaged into a standardized network data packet according to the protocol specification and written into the bidirectional network data sending buffer queue of the network thread; when it is detected that the network sending buffer is writable, the pending data in the buffer queue is written into the network sending buffer in batches, and the request is recorded in the service request sent queue; Server processing: After the network thread of the server receives the service call request initiated by the client, the service call request is distributed to the service request to be processed queue maintained by the corresponding processing thread according to the preset allocation strategy; Response processing and feedback: The processing thread takes the request from the service request to be processed queue and processes it; after completing the business logic processing, the processing result is fed back to the service consumer according to the agreed protocol specification through the network thread; Response notification: After the network thread of the service consumer receives the response data packet of the service provider, the corresponding request record is removed from the service request sent queue, and the processing result is notified to the caller through the asynchronous callback mechanism or the blocking queue.

Images