Module fusion integration method and device for small molecule drug design

Abstract

The invention discloses a module fusion integration method and device for small molecule drug design, and the device comprises a front-end integration layer which is constructed based on a Vue framework, is used for providing a unified user interface and modular function integration, and comprises an interface fusion module, an authentication control module and a state management module; the Web service middleware layer is used as a system logic center, comprises a RESTfu API routing module, a parameter template engine module and a module calling interface module, and is used for request forwarding, parameter standardization and module scheduling; the module service layer is used for registration and management of heterogeneous computing modules, comprises a service registration module, an interface adapter module and a configuration management module, and supports dynamic loading and combined calling of the modules; and the infrastructure layer provides physical computing resources, comprises a GPU / CPU resource pool and a distributed storage system, and is used for executing computing tasks and persistent data storage. According to the device, the multi-source AI module can be efficiently and flexibly integrated, and the integration process is simplified.

Description

Technical Field

[0001] The present invention relates to the technical field of system integration design, and in particular, to a method and device for modular fusion integration for small molecule drug design. Background Art

[0002] With the wide application of artificial intelligence technology in drug research and development, numerous artificial intelligence (AI) modules with different functions have emerged, such as molecular generation, target prediction, and assessment of pharmacokinetics methods (ADMET). These modules are usually developed by different teams or institutions and lack a unified integration standard, resulting in poor system compatibility, complex data transfer, and poor user experience. Existing integration methods mostly adopt static coupling, which is difficult to adapt to the rapidly changing research and development needs, and often requires a large amount of manual configuration when modules are updated or replaced, increasing the maintenance cost. Therefore, there is an urgent need for a method that can efficiently and flexibly integrate multi-source AI modules. Summary of the Invention

[0003] To solve the problems existing in the prior art, the embodiments of the present application provide a method, a device, a computing device, a computer storage medium, and a product including a computer program for modular fusion integration for small molecule drug design, which can efficiently and flexibly integrate multi-source AI modules, simplify the integration process, improve the scalability and maintainability of the system, and enhance the intelligence and automation level of new drug research and development.

[0004] In a first aspect, the embodiments of the present application provide a device for modular fusion integration for small molecule drug design, including: a front-end integration layer, built based on the Vue framework, for providing a unified user interface and modular function integration, including an interface fusion module, an authentication control module, and a state management module; a Web service middleware layer, serving as the system logic center, including a RESTful API routing module, a parameter template engine module, and a module call interface module, for request forwarding, parameter standardization, and module scheduling; a module service layer, for registration and management of heterogeneous computing modules, including a service registration module, an interface adapter module, and a configuration management module, supporting dynamic loading and combined invocation of modules; an infrastructure layer, providing physical computing resources, including a GPU / CPU resource pool and a distributed storage system, for executing computing tasks and persistent data storage.

[0005] In some possible implementation manners, the authentication control module of the front-end integration layer implements a unified authentication mechanism based on OAuth2.0 / JWT and automatically injects authentication information when switching modules.

[0006] In some possible implementation manners, the parameter template engine module of the Web service middleware layer adopts the YAML configuration format and supports the dynamic construction, verification, and semantic adaptation of input parameters.

[0007] In some possible implementation manners, the interface adapter module of the module service layer encapsulates modules implemented in different programming languages into a unified RESTful interface.

[0008] In some possible implementation manners, the GPU / CPU resource pool of the infrastructure layer realizes containerized orchestration through Kubernetes and supports the dynamic allocation and recycling of computing resources.

[0009] In some possible implementation manners, the state management module of the front-end integration layer realizes cross-module data sharing and state synchronization through Vuex.

[0010] In some possible implementation manners, the configuration management module of the module service layer pre-sets multiple drug design task templates and supports parameter pre-filling and modular combined calls.

[0011] In some possible implementation manners, the distributed storage system stores the calculation results by adopting a multi-copy mechanism and supports cross-module data reuse.

[0012] In some possible implementation manners, the Web service middleware layer implements a secondary token conversion mechanism to convert the user's main token into a module-specific access credential.

[0013] In a second aspect, an embodiment of the present application provides a module fusion and integration method for small molecule drug design, including: determining a target function module selected by a user through the front-end integration layer, receiving a calculation request submitted by the user, and the front-end integration layer realizing modular interface fusion and unified authentication based on the Vue framework; the Web service middleware layer receiving the calculation request, routing and distributing it to the target module through the RESTful API, and performing standardized conversion and verification on the input parameters by using the YAML parameter template engine; the module service layer dynamically scheduling heterogeneous computing modules, and if the target module is not activated, applying for GPU / CPU resources from the infrastructure layer and starting a containerized service instance; the infrastructure layer executing the calculation task, and the result is returned to the front end through the middleware layer and persistently stored in the distributed file system to support cross-module data reuse.

[0014] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, including computer-readable instructions, and when a computer reads and executes the computer-readable instructions, the computer is enabled to execute the method according to any item in the first aspect.

[0015] Fourth aspect, an embodiment of the present application provides a computing device, including a processor and a memory. Wherein, computer program instructions are stored in the memory, and when the computer program instructions are run by the processor, the method described in any item of the first aspect is executed.

[0016] Fifth aspect, an embodiment of the present application provides a product containing a computer program. When the computer program product runs on a processor, the processor is caused to execute the method described in any item of the first aspect. Description of the Drawings

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for description in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0018] Figure 1 is a logical architecture diagram of a module fusion and integration device for small molecule drug design provided by an embodiment of the present application;

[0019] Figure 2 is a flow schematic diagram of a module fusion and integration method for small molecule drug design provided by an embodiment of the present application;

[0020] Figure 3 is a schematic diagram of interface display provided by an embodiment of the present application. Detailed Embodiments

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

[0022] The term "and / or" in this article is an association relationship describing associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. The symbol " / " in this article represents an "or" relationship between associated objects. For example, A / B represents A or B.

[0023] In the description of the specification and claims in this document, terms such as "first" and "second" are used to distinguish different objects, rather than to describe a specific order of the objects. For example, a first response message, a second response message, etc. are used to distinguish different response messages, rather than to describe a specific order of the response messages.

[0024] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner.

[0025] In the description of the embodiments of this application, unless otherwise specified, the meaning of "a plurality of" refers to two or more. For example, a plurality of processing units refers to two or more processing units, etc.; a plurality of elements refers to two or more elements, etc.

[0026] For the convenience of understanding the embodiments of this application, the following will further explain with specific embodiments in conjunction with the accompanying drawings. The embodiments do not constitute a limitation on the embodiments of the present invention.

[0027] Existing artificial intelligence drug design tools and platforms are often independent of each other and lack a unified integration mechanism. Different types of drug design tasks (such as small molecule generation, protein structure analysis, antibody-drug conjugate ADC design, etc.) usually use different software tools and are designed and completed by different teams in different programming languages. Due to the lack of a unified platform, users need to switch between multiple incompatible systems during the research process, resulting in difficult data sharing and cumbersome operation processes. In addition, most traditional platforms are of a single architecture, with the front-end interface tightly coupled to the back-end logic, making it difficult to expand modules, having inconsistent interface styles, and being unable to flexibly add new AI model services. These limitations have largely hindered cross-disciplinary drug design collaboration and the rapid application of new algorithms.

[0028] In view of this, the embodiments of this application provide a module fusion and integration method for small molecule drug design. By implementing multi-module integration under a Web framework, AI drug design modules from different sources and using different technical languages are organically integrated into a unified system. The platform adopts an architecture with separation between the front-end and the back-end: the back-end is based on a lightweight Web framework, Spring boot, to build a RESTful interface service, and the front-end uses the Vue framework to build a single-page application interface. Through a flexible mounting mechanism and decoupling design of the modules, each functional module can be plugged into the platform like a plugin, while maintaining a unified user interface and interaction experience.

[0029] Exemplarily, Figure 1The figure shows the logical architecture diagram of a module fusion and integration device for small molecule drug design provided by an embodiment of the present application. As Figure 1 shown, the module fusion and integration device adopts a four-layer hierarchical architecture, namely the front-end integration layer, the Web service middleware layer, the module service layer, and the infrastructure layer. Through a multi-layer decoupled system design, this architecture realizes the flexible combination, unified scheduling, and optimized use of resources of multi-source intelligent modules, and is particularly suitable for task links such as the generation, screening, optimization, and evaluation of small molecule compounds.

[0030] Among them, the front-end integration layer consists of sub-modules such as module interface fusion, authentication control, and status management. Users access various AI module services provided by the platform through the front-end interface. The front-end is built using the Vue framework and adopts a component-based design to achieve the pluggability of each module interface. To ensure the continuity of the user identity and the module access rights, the platform introduces a unified authentication control module at this layer. Based on the OAuth2.0 or JWT token mechanism, the authentication information is automatically injected during module switching and request dispatching. The status management module manages cross-module shared variables (such as user input, calculation results, intermediate parameters) with the help of the Vuex state tree to ensure the consistency of data when the user switches between multiple modules.

[0031] Specifically, as the direct entry for users to interact with the platform, the front-end integration layer undertakes core functions such as module interface fusion, unified authentication, and status synchronization. Its design goal is to achieve seamless integration of multi-source heterogeneous AI modules and a consistent user experience. Built on the Vue framework, this layer makes full use of its component-based and reactive features. Through a modular architecture and standardized protocols, it ensures that different drug design tools can be plugged into the platform in a pluggable manner while maintaining a high degree of unity in the interface style, operation process, and data status.

[0032] In terms of module interface fusion, the front-end integration layer adopts a dynamic component loading and nesting strategy, embedding the interfaces of third-party modules into the platform main framework in the form of independent Vue components. For modules that natively support component-based development, they are directly compiled into Vue single-file components and registered in the platform's routing system through a dynamic routing mechanism; for existing systems with strong closure, integration is achieved through iframe cross-domain nesting, and the postMessage protocol is used to solve the cross-domain communication problem. The platform provides a unified layout template, including common areas such as navigation menus, headers, footers, and status bars. The interfaces of all modules need to inherit the style specifications of this template to ensure a consistent visual style. In addition, through the global CSS variable and theme injection mechanism, the platform can dynamically adjust style attributes such as color matching and fonts to further strengthen the integrity.

[0033] In terms of authentication control, the platform adopts the OAuth2.0 or JWT token mechanism to achieve unified identity authentication. The main token obtained after the user logs in is securely stored by the front end and automatically appended to the request header in all subsequent requests. When the user switches modules, the front end dynamically checks the access permissions according to the module's permission configuration, and the module entry without permission will be hidden or disabled. For scenarios that need to call third-party modules, the front-end integration layer will convert the main token into a module-specific temporary token through the middleware service to avoid the security risks brought by directly exposing the main token. The validity period and refresh policy of the temporary token are centrally managed by the platform and automatically renewed without the user's awareness, ensuring that long-term operations will not be interrupted due to token expiration. In addition, the front end also integrates fine-grained operation permission control, such as dynamically hiding or disabling specific buttons according to the user role to prevent users from performing unauthorized operations.

[0034] In terms of state management, the state management module is responsible for maintaining the data state shared across modules, solving the problems of parameter passing and result echo in the multi-step drug design process. Based on the state tree design of Vuex, the platform centrally stores key data such as user input, calculation intermediate results, and task execution status, and defines strict change rules to ensure the traceability of state updates. For example, the parameters set by the user in the "molecule generation" module can be automatically filled when switching to the "activity prediction" module without repeated input. The state management module also implements the data persistence ability, and the user can still restore the previous operation context after refreshing the page or logging in again. For large-scale data (such as molecular structure files), the front end adopts the lazy loading and local caching strategy to reduce the network transmission overhead. At the same time, the state module is linked with the logging system to record the user operation path and key state changes, providing a basis for subsequent analysis and optimization.

[0035] The Web service middleware layer is the logical center of the platform, responsible for all data transfer and logic coordination between the front and back ends and between modules. The main functional modules include the RESTful API routing module, the parameter template engine module, and the module call interface module. Among them, the RESTful API routing module is used to achieve the logical decoupling between the front-end request and the back-end module, and organizes the call entry of each functional module through a unified interface specification. The parameter template engine module is based on the YAML configuration format, supporting the dynamic construction, verification, and standardized conversion of input parameters to ensure the parameter semantic compatibility between different modules. The module call interface is used to provide a unified mechanism for module activation, interface distribution, and call feedback, supporting module-level status polling and error fallback to improve the stability and robustness of the system operation.

[0036] Specifically, the Web service middleware layer, as the central system of the entire platform, undertakes core functions such as request routing, parameter adaptation, and service scheduling. It is a key bridge connecting the front-end user operations and the back-end AI modules. This layer is designed with a lightweight microservices architecture and implements high-concurrency and low-latency request processing capabilities based on technology stacks such as Spring Boot, ensuring that the platform can still operate efficiently and stably in the face of complex and variable workflows in drug research and development. In terms of request routing, the middleware layer unifies the access entrances of all functional modules through the RESTful API specification. Requests initiated by the front-end are first parsed and distributed by the API routing module. The routing module maintains a dynamic registry that records the URL paths of each back-end module, the supported HTTP methods, and the required permission levels. When a request arrives, the routing module matches the specific back-end service according to the URL path and simultaneously verifies the legality of the request and the user permissions to prevent unauthorized access. For complex scenarios that require combined cross-module calls, the routing module also supports chained forwarding of requests. For example, the output of the molecular generation module is automatically passed to the subsequent activity prediction module, and the whole process is completely transparent to the user.

[0037] The parameter template engine is specifically used to solve the parameter compatibility problem between heterogeneous modules. In drug research and development, different AI tools have very different requirements for input parameters. For example, some modules require molecular descriptions in SMILES format, while others accept three-dimensional structure files. The traditional method requires users to manually convert the format, which is inefficient and error-prone. The parameter template engine describes the input and output specifications of each module through a predefined YAML configuration file, including meta-information such as parameter names, data types, value ranges, and whether they are required. When a user submits a request, the engine automatically verifies the parameter integrity according to the template and converts the parameters into the standardized format required by the target module. For example, the molecular structure input by the user at the front-end may be uniformly converted into a JSON-format molecular description object, and then a SMILES string or molecular fingerprint is derived according to the requirements of different modules. The template engine also supports parameter mapping and default value filling. When the parameter names of two modules are inconsistent, an alias relationship can be established through configuration; for optional parameters, the engine automatically fills in the default values, reducing the user's repeated input. This configuration-based parameter management method significantly reduces the development cost of module integration. New modules can be quickly integrated into the platform by simply adding the corresponding YAML description file.

[0038] The module call interface component is responsible for coordinating the lifecycle and call process of backend services. This component can maintain a registry of active modules, recording the running status, resource occupancy, and health metrics of each module. When the routing module forwards a request, the call interface first checks whether the target module is in an available state. If the module has not been started (such as an AI service deployed in a container), it will automatically trigger the service startup process, allocate necessary computing resources from the infrastructure layer, and initialize the service instance. During the execution of the module, the call interface monitors the task progress in real time, detects service anomalies through the heartbeat mechanism. Once timeouts or errors are found, it immediately initiates the retry or failover process to ensure that user requests are not lost due to single-point failures. For long-running tasks, the call interface supports an asynchronous callback mechanism, actively notifying the front end after the task is completed to avoid long waiting times for users. In addition, this component also implements intelligent load balancing. When multiple users call the same module simultaneously, it dynamically allocates requests based on the current load of module instances, preventing resource waste where some instances are overloaded while others are idle.

[0039] The module service layer is the registration and adaptation layer for heterogeneous functional modules and a key component for the flexible expansion of the system and the integration of heterogeneous models. The main functional modules include the service registration module, the interface adapter module, and the configuration management module. Among them, the service registration module supports the dynamic declaration of self-developed or third-party module services and completes registration by configuring module metadata (including model type, interface specification, input and output formats, etc.). The interface adapter module can resolve differences in the languages and call protocols used between modules, support RESTFul access, and provide a consistent call interface through unified encapsulation. The configuration management module pre-sets module combination templates for different drug design tasks, supporting parameter pre-filling, version switching, etc., to facilitate the rapid deployment of typical design processes.

[0040] Specifically, the module service layer, as the key layer connecting the upper and lower levels in the system, is specifically responsible for the standardized access and collaborative management of heterogeneous AI modules. This layer adopts a microkernel architecture design. Through three major functional modules: service registration, interface adaptation, and configuration management, the originally scattered and independent drug design tools are transformed into platform resources that can be uniformly scheduled and flexibly combined. The service registration module, as the first checkpoint for module access, adopts a declarative metadata management mechanism. Each AI module that needs to access the platform must register its function description and technical specifications here. The registration information not only includes basic attributes such as module name, version number, and developer, but more importantly, defines the technical characteristics of the module, such as the supported input and output data types (SMILES strings, molecular descriptors, 3D structure files, etc.), computing resource requirements (GPU video memory size, CPU core count), execution mode (synchronous / asynchronous), and performance metrics (estimated computing time). These metadata are stored in the platform's module repository in the form of JSON Schema. When a new module completes registration, the platform will automatically generate corresponding API documents and parameter templates for the front-end interface and middleware layer to call and reference. For third-party commercial software, the registration module also supports the management and verification of license keys to ensure compliance in use.

[0041] The interface adapter module is the core component for solving technical heterogeneity and can transform AI modules implemented in different programming languages and technical protocols into platform-standardized service interfaces. In the field of drug research and development, common modules may be based on Python (such as RDKit, PyTorch), R language (such as Bioconductor), or even traditional commercial software (such as Schrodinger Suite), and their calling methods vary greatly. The adapter module provides corresponding encapsulation plugins for each technology stack. For example, it encapsulates Python modules as Flask REST services, wraps command-line tools as HTTP interfaces, or bridges high-performance computing clusters through GRPC. All adapters ultimately output a unified RESTful interface specification, hiding the underlying implementation details, so that the middleware layer can call various modules without distinction. The adapter also implements protocol conversion functions, such as converting HTTP requests into SOAP messages required by specific modules, or converting JSON parameters into text input files required by Fortran programs. To improve performance, the adapter will perform cache optimization on frequently called module interfaces. For example, the results of the molecular descriptor calculation module will be automatically cached, and when the same input appears again, the cached value will be directly returned to avoid repeated calculations.

[0042] The configuration management module is like an experienced laboratory steward. Through predefined templatized configurations, it combines scattered modules into a complete drug R & D workflow. This module maintains a task template library, and each template describes the module execution sequence and parameter passing rules under a specific R & D scenario. For example, the "lead compound optimization" template may sequentially call three modules: molecular generation, ADMET prediction, and molecular docking, and automatically convert the output of the previous module into the input format of the next module. Users only need to select a template, and the platform will automatically fill in all intermediate parameters, greatly reducing the operation complexity. Configuration management also supports module version control. When there are multiple versions of the same type of module on the platform (such as molecular generators implemented by different algorithms), users can easily switch and compare. For parameter combinations that need to be adjusted frequently, users can save them as personal configuration schemes to form their own R & D toolkits. The dependency relationships between modules are also managed by this component. For example, some molecular dynamics simulation modules need to call the force field parameterization module first, and the configuration management will automatically handle this precondition check.

[0043] Through the standardized encapsulation and flexible scheduling of the module service layer, the originally independent drug design tools can be transformed into an intelligent network that can cooperate with each other. Whether it is an innovative algorithm developed by an academic institution or a professional module provided by commercial software, it can quickly integrate into the platform ecosystem. Researchers no longer need to spend a lot of time learning the usage methods of different tools, but can focus on the scientific problems themselves, explore more R & D paths through the free combination of modules, and greatly accelerate the conversion efficiency from molecular design to preclinical research. This open architecture design also reserves space for the future technological evolution of the platform. When new AI technologies (such as quantum computing, generative models) emerge, they can be quickly integrated into the existing platform in a modular form to continuously enhance the intelligent level of drug R & D.

[0044] The infrastructure layer provides physical computing and data storage capabilities for the module fusion and integration device of small molecule drug design, including GPU / CPU resource pools and distributed storage systems. Among them, the GPU / CPU resource pool refers to the platform accessing a multi-node heterogeneous computing environment, supporting NVIDIA GPU parallel computing and high-concurrency CPU task execution, supporting the operation of deep learning models, graph neural network prediction, and structure optimization tasks in small molecule generation and screening, and realizing resource allocation on demand through a unified scheduling strategy. The distributed storage system uniformly stores the calculation results, model caches, and intermediate data in a distributed file system that supports multi-tenancy and permission control, ensuring data persistence and reusability between tasks.

[0045] Specifically, as the physical support of the entire drug design platform, the infrastructure layer provides powerful computing capabilities and reliable data storage services for various upper-layer AI modules, and is the key foundation to ensure the efficient operation of high-throughput drug screening and complex molecular simulations. This layer adopts a cloud-native architecture design. Through virtualization technology and distributed systems, heterogeneous hardware resources are transformed into elastically scalable platform services to meet the full-process computing requirements from molecular generation to property prediction in drug research and development. In terms of computing resources, the infrastructure layer constructs a hybrid GPU / CPU resource pool, which not only includes high-performance GPU nodes equipped with NVIDIA Tesla series graphics cards for running computationally intensive tasks such as deep learning models and graph neural networks, but also deploys a multi-core CPU server cluster to handle traditional computing tasks such as molecular docking and quantum chemistry calculations. The resource pool is uniformly managed through container orchestration tools such as Kubernetes. The platform can dynamically allocate resources according to the computing requirements of the modules. For example, the molecular generation module may be scheduled to a node equipped with an A100 graphics card to obtain the best performance, while simple data preprocessing tasks are assigned to CPU nodes to save GPU resources. The resource scheduler adopts an intelligent strategy, comprehensively considering multiple factors such as task priority, computing time consumption, and resource utilization rate, to avoid the situation where some nodes are overloaded while others are idle. For particularly time-consuming tasks such as molecular dynamics simulations, the infrastructure layer also supports cross-node parallel computing, splitting large tasks into multiple subtasks for distributed execution, significantly shortening the overall computing time.

[0046] The distributed storage system solves the problems of large-scale data persistence and shared access in drug research and development. The system is built based on open-source distributed file systems such as Ceph, and adopts a multi-copy mechanism to ensure data reliability. Even if a single node fails, data loss will not occur. The storage space is logically divided into multiple areas, including the original dataset area (storing public molecular libraries, protein structure databases, etc.), the intermediate result area (saving temporary files calculated by modules), the user work area (personal experimental data), and the model repository (parameter files of pre-trained AI models). Fine-grained permission control is implemented for each area, and users can only access authorized data. The storage system specifically optimizes typical data access patterns in small molecule drug research and development. For example, a combined storage strategy is adopted for small files such as SMILES sequences and molecular descriptors to reduce metadata overhead, and streaming reading is supported for large files such as molecular dynamics trajectories to avoid memory overflow. The system also implements an intelligent caching mechanism, and popular datasets will be automatically cached locally on the computing nodes to reduce network transmission latency. All data operations are detailedly recorded to form a complete audit log, meeting the strict requirements of the pharmaceutical industry for the traceability of experimental data.

[0047] Based on this module fusion and integration device, an embodiment of the present application provides a module fusion and integration method. The following combines Figure 1 WithFigure 2 The multi-cover method will be introduced. Exemplarily, Figure 2 FIG. shows a schematic flowchart of a module fusion and integration method for small molecule drug design provided by an embodiment of the present application. As Figure 2 shown, the method may include the following steps:

[0048] S21: Determine the target function module selected by the user through the front-end integration layer, receive the calculation request submitted by the user, and the front-end integration layer realizes modular interface fusion and unified authentication based on the Vue framework.

[0049] In this embodiment, after the user successfully logs in to the system, the front-end integration layer will load the main interface built based on the Vue framework. This interface adopts a responsive design and can adapt to different sizes of screen devices. The system will first dynamically generate a list of accessible function modules according to the user's permission level. These modules are displayed in the left navigation area of the interface in the form of icon cards or tree menus. Figure 3 FIG. shows a schematic diagram of an interface display provided by an embodiment of the present application. The user can select the target function module through click or touch operations. For example, select Figure 3When the "Target Research Module" as shown is loaded, the front end will load the corresponding module components through the dynamic routing function of VueRouter. During the module loading process, the system will display a loading animation to enhance the user experience, and at the same time check whether the user has the operation permission for this module. If the permission verification passes, the module interface will be fully presented; if there is no permission, a prompt message indicating insufficient permission will be displayed. After the user selects the "Target Research Module", they will see the dedicated operation interface of this module. The interface layout follows the unified UI design specifications of the platform, including standard blocks such as a parameter input area, a result display area, and an operation button area. The user fills in various data required for target research in the parameter input area, such as protein sequences, binding site information, research parameter settings, etc. The platform will verify the data format and validity of the user input in real time, such as checking whether the protein sequence conforms to the FASTA format requirements and whether the numerical parameters are within a reasonable range. When the user clicks the submit button, the front end will trigger a series of standardized operations: first, encapsulate the user input data and module configuration information into a structured JSON object, then obtain the current user's identity authentication token (JWT format) from the Vuex state management, and initiate a POST request with this information through the axios library. The request will first pass through the unified routing processor of the front end, which will add necessary metadata to the request, including the module version number, client environment information, timestamp, etc., to ensure the integrity and traceability of the request. Throughout the process, the front end integration layer maintains a unified state management mechanism. The global state managed by Vuex includes user identity information, module access records, cross-module shared data, etc. For example, when the user submits data in the target research module, the system will automatically record this operation in the state tree for subsequent query of the operation history. At the same time, the platform has implemented a fine-grained permission control system, which not only controls the access permissions at the module level but also manages specific operation permissions. For example, some users may only be able to view the results but not submit new tasks. All API requests will automatically carry the identity token, and the front end will uniformly add the Authorization request header to ensure that the back-end service can accurately identify the request source. For long-running tasks, the front end will establish a WebSocket connection to receive real-time task status updates and display a progress bar and estimated completion time on the interface to enhance the user experience. After the task is completed, the result data will be formatted and presented in the interface display area, and at the same time, it will be automatically saved to the user's personal workspace for subsequent analysis.

[0050] S22: The web service middleware layer receives the calculation request, distributes it to the target module through the RESTful API routing, and uses the YAML parameter template engine to perform standardized conversion and verification on the input parameters.

[0051] In this embodiment, when the computing request submitted by the user from the front end arrives at the Web service middleware layer, the RESTful API routing component in the middleware layer identifies and forwards the user request, and accurately distributes it to the service interface of the corresponding target function module. To ensure high availability, the routing component obtains the list of available instances of the target module from the service registry, and then selects the most suitable instance for request forwarding based on the round-robin algorithm or the least load strategy. Before forwarding, the system calls the parameter processing pipeline to preprocess the request data. The core of this pipeline is the YAML parameter template engine, which converts and validates the input data according to the predefined parameter specifications. Each function module has a corresponding YAML configuration file, which details the meta-information such as the parameter structure, data type, value range, and whether it is required for this module. The engine first checks whether the required fields are complete, and then performs type conversion and normalization processing on each parameter value. For example, it converts a number in string form to a numeric type and formats the date string into the ISO8601 format. For complex nested parameters, the engine recursively applies these conversion rules. The parameter verification stage performs more stringent business rule checks, such as ensuring that the lower limit of the molecular weight range is not greater than the upper limit, and verifying that the protein sequence only contains standard amino acid codes. Parameters that fail the verification will generate detailed error messages and be returned to the front end through a unified error response format. The parameters that pass the verification will be assembled into a structured data object, which not only contains the original data submitted by the user, but also attaches system-generated metadata, such as the request ID, timestamp, user context, etc. The engine also processes the dependency relationships between parameters. For example, when a certain flag is set to true, the default value is automatically filled for the associated parameter. The parameter object that has completed the standardization process will be injected into the request context and sent to the service endpoint of the target module together with the forwarded request. For particularly complex parameter structures, the system supports a template inheritance mechanism, allowing common parameter definitions to be reused by multiple modules. This design enables new modules to be quickly integrated by only defining the differentiated parameters. The parameter engine also supports dynamic template loading. When the module updates the parameter specifications, it takes effect without restarting the service. All parameter conversion and verification operations are efficiently completed in memory, ensuring that the system can quickly respond to a large number of concurrent requests. The processed standardized parameters provide a clear and consistent input interface for the subsequent module service layer, greatly reducing the integration complexity between modules.

[0052] S23: The module service layer dynamically schedules heterogeneous computing modules. If the target module is not activated, it applies for GPU / CPU resources from the infrastructure layer and starts a containerized service instance.

[0053] In this embodiment, when a calculation request is forwarded by the Web service middleware layer to the module service layer, the system will first query the real-time status table of the module registry to check whether the target function module is currently in an available state. The registry maintains detailed metadata of all connected modules, including module deployment types (such as Docker containers, Serverless functions, or native processes), resource requirement specifications (GPU models, memory sizes, etc.), health check endpoints, and other information. If it is found that the target module has not been activated or all instances are busy, the module scheduler will immediately trigger the resource application process. The scheduler will first generate a resource description file according to the resource configuration requirements of the module. For example, for a molecular dynamics simulation module that requires GPU acceleration, it will apply for a node equipped with an NVIDIA T4 graphics card and specify the CUDA version and video memory requirements; for an analysis module that has no requirements for analysis speed, it may only need to be configured with 2-core CPUs and 4GB of memory. These resource requests are sent to the resource orchestration engine in the infrastructure layer, which is implemented based on Kubernetes and supports hybrid cloud resource scheduling. After receiving the request, the orchestration engine will select appropriate physical nodes or virtual machine instances from the resource pool and then pull the pre-installed Docker image to start the container. The image repository stores the customized running environments of each module, which have integrated all necessary dependency libraries and runtime environments. During the container startup process, the system will dynamically inject configuration parameters, including sensitive information such as database connection strings, API keys, and calculation parameters. These information comes from the platform's key management system and is transmitted in the form of temporary tokens to avoid hard coding in the image. At the same time, the service mesh component will automatically configure network policies and service discovery mechanisms for the newly created container instances so that they can be accessed by other modules and the front end. After the container completes initialization, the health check service will periodically probe the / health endpoint of the module until it is confirmed that the service is fully ready. The ready signal will trigger the registry to update the module status and add this new instance to the load balancing pool. At this time, the original user request will be re-routed to this newly started instance for processing. For short-term tasks, the system may choose to start a serverless function (such as AWS Lambda) to run the calculation. In this scenario, the platform will pre-package the user input data and module code into a function payload and trigger the execution in an event-driven manner. Regardless of the deployment form used, the module service layer will maintain a complete lifecycle record, including startup time, resource consumption, running logs, etc. These data are used for subsequent billing accounting and performance optimization. When the module is idle for a long time (according to the configured policy, such as no request for 30 minutes), the resource recycler will automatically release the relevant resources, but will retain the container image in the local cache to speed up the next startup.

[0054] S24: The infrastructure layer executes computing tasks. The results are returned to the front end via the middleware layer and persistently stored in the distributed file system, supporting cross-module data reuse.

[0055] In this embodiment, the module execution phase will be completed at the backend infrastructure layer, and the scheduled GPU / CPU resource pool will be utilized to execute the computing tasks. During the computing process, the system will monitor the resource usage in real time, including indicators such as GPU video memory occupancy, CPU utilization, and disk I / O. These monitoring data are used both for the optimization scheduling of the current task and as historical data for subsequent resource planning. For long-running tasks, such as molecular dynamics simulations, the system will periodically generate checkpoint files. In case of hardware failures or task interruptions, the computing can be resumed from the most recent checkpoint, avoiding the resource waste caused by full recalculation. The raw results generated by the computing are first written to the local high-speed cache of the node, and then are subjected to format conversion and compression optimization by a dedicated result processing pipeline. For example, the molecular docking results may be converted from a binary format to a more common JSON structure, and the 3D molecular conformation data is compressed using gzip to reduce the network transmission volume. The processed result data will be transmitted through the high-speed intranet to the distributed file system cluster, where a multi-copy storage strategy is adopted, and by default, 3 copies are saved on different physical racks to ensure high data availability. The storage system maintains an independent namespace for each user and implements role-based access control. Users can only view and operate on the data to which they have access permissions. All result files will automatically generate rich metadata, including key information such as computing parameters, software versions, and execution times. These metadata are simultaneously written to the scientific research data warehouse of the platform to support subsequent complex retrieval and analysis. While the data is being persisted, the computing results will also be returned to the Web service middleware layer in real time through a message queue. The middleware layer performs the final encapsulation and standardization processing on the results, including adding information such as a unified result status code, computing time consumption statistics, and digital signature, and then returns the response to the front end through the REST API. After receiving the results, the front-end interface will call the corresponding visualization components for rendering according to the data type. For example, a 3D molecular viewer is used to display the protein-ligand complex structure, and an interactive chart is used to display the dose-effect curve of the activity data. The system will also automatically extract the key indicators from the results and generate structured summary information. These summaries are cached in the state management of the front end to facilitate users to quickly obtain the core conclusions of the previous computations when switching between different modules. The complete result data stored in the distributed file system can be referenced and reused within any module in the platform through a unique task ID. For example, the compounds designed in the molecular generation module can be directly used as the input ligands for the molecular docking module, and the system will automatically handle the conversion and transfer of the data format. The platform also provides a complete data version management function. The input parameters and output results of each computation are completely saved, forming a traceable research chain to support the reproduction and auditing of the computing results.

[0056] The above is the introduction to the module fusion and integration method for small molecule drug design provided by the embodiments of this application. After the user logs in, the front-end integration layer dynamically loads the target module interface based on the Vue framework, completes unified authentication through JWT / OAuth2.0, and submits parameter requests to the Web middleware layer; the middleware distributes requests through RESTful API routing, and uses the YAML template engine to perform standardized verification and format conversion on the input parameters; the module service layer checks the status of the target module. If it is not activated, it schedules the infrastructure layer to start a containerized instance and dynamically allocates GPU / CPU resources to execute computing tasks; the calculation results are returned to the front-end for visual display through the middleware, and are simultaneously persistently stored in the distributed file system to support cross-module data reuse. In the process, the Vuex state tree is used to maintain data consistency, the secondary token mechanism ensures secure communication between modules, and containerized orchestration realizes elastic resource scheduling, forming a closed-loop drug R & D workflow from user requests to result reuse. This method realizes the efficient integration and collaborative work of multiple drug design function modules through multi-layer architecture design, containerized orchestration, and dynamic configuration management, significantly improving the intelligence and automation level of drug R & D.

[0057] It can be understood that the magnitudes of the sequence numbers of the steps in the above respective embodiments do not mean the order of execution. The order of execution of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of this application. In addition, in some possible implementation manners, the steps in the above embodiments can be selectively executed according to actual situations, can be partially executed, or can be fully executed, which is not limited herein. Any feature of any embodiment of this application, in whole or in part, can be freely combined in any way without conflict. The combined technical solution is also within the scope of this application.

[0058] Based on the method in the above embodiments, an embodiment of this application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program runs on a processor, it causes the processor to execute the methods in the above respective embodiments.

[0059] Based on the method in the above embodiments, an embodiment of this application provides a computer program product. When the computer program product runs on a processor, it causes the processor to execute the methods in the above respective embodiments.

[0060] It can be understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0061] The method steps in the embodiments of the present application may be implemented in a hardware manner or by a processor executing software instructions. The software instructions may be composed of corresponding software modules, and the software modules may be stored in a random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, removable hard disks, CD-ROMs, or any other form of storage medium well-known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium may also be a component of the processor. The processor and the storage medium may be located in an ASIC.

[0062] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)), etc.

[0063] It can be understood that the various numerical numbers involved in the embodiments of the present application are only for the convenience of description and are not used to limit the scope of the embodiments of the present application.

Claims

1. A module fusion and integration device for small molecule drug design, characterized in that, The device includes: A front-end integration layer, built based on the Vue framework, used to provide a unified user interface and modular function integration, including an interface fusion module, an authentication control module, and a state management module; A Web service middleware layer, serving as the system logic center, including a RESTful API routing module, a parameter template engine module, and a module call interface module, used for request forwarding, parameter standardization, and module scheduling; A module service layer, used for the registration and management of heterogeneous computing modules, including a service registration module, an interface adapter module, and a configuration management module, supporting the dynamic loading and combined invocation of modules; An infrastructure layer, providing physical computing resources, including a GPU / CPU resource pool and a distributed storage system, used for executing computing tasks and persistent data storage.

2. The device according to claim 1, characterized in that The authentication control module of the front-end integration layer implements a unified authentication mechanism based on OAuth2.0 / JWT and automatically injects authentication information when switching modules.

3. The device according to claim 1, wherein The parameter template engine module of the Web service middleware layer adopts the YAML configuration format, supporting the dynamic construction, verification, and semantic adaptation of input parameters.

4. The device according to claim 1, characterized in that, The interface adapter module of the module service layer encapsulates modules implemented in different programming languages into a unified RESTful interface.

5. The device according to claim 1, wherein, The GPU / CPU resource pool of the infrastructure layer realizes containerized orchestration through Kubernetes, supporting the dynamic allocation and recycling of computing resources.

6. The device according to claim 1, characterized in that, The state management module of the front-end integration layer realizes cross-module data sharing and state synchronization through Vuex.

7. The device according to claim 1, wherein The configuration management module of the module service layer pre-sets multiple drug design task templates, supporting parameter pre-filling and combined module invocation.

8. The device according to claim 1, characterized in that, The distributed storage system stores computing results using a multi-copy mechanism and supports cross-module data reuse.

9. The device according to claim 1, characterized in that, The Web service middleware layer implements a secondary token conversion mechanism to convert the user's main token into a module-specific access credential.

10. A module fusion and integration method for small molecule drug design, characterized in that, The method includes: Determining the target function module selected by the user through the front-end integration layer, receiving the computing request submitted by the user, and the front-end integration layer realizing modular interface fusion and unified authentication based on the Vue framework; The Web service middleware layer receives the computing request, distributes it to the target module through the RESTful API routing, and uses the YAML parameter template engine to perform standardized conversion and verification on the input parameters; The module service layer dynamically schedules heterogeneous computing modules. If the target module is not activated, it applies for GPU / CPU resources from the infrastructure layer and starts a containerized service instance; The infrastructure layer executes the computing task, and the result is returned to the front end through the middleware layer and persistently stored in the distributed file system, supporting cross-module data reuse.

Images