A Remote Invocation Dynamic Extension Method Based on Java Dynamic Bytecode

Abstract

This invention relates to the field of information technology, specifically to a method and system for dynamically extending remote invocation based on Java dynamic bytecode. The method includes: establishing a C / S architecture, setting up a communication channel between the client and server, with the server providing an interface for maintaining remote invocation tasks of Java source code type; defining remote tasks of Java source code type through the interface, dynamically pre-compiling the Java source code into task bytecode using Javassist, and storing it on the server; the server initiating a remote invocation to a specified client using remote invocation task ID, version number, and business data as parameters; the client creating a custom ClassLoader to remotely load the task bytecode from the server and generate a Java class; and the client executing the method of the remote task object and returning the invocation result. This invention performs a single compilation, allowing multiple clients to run the code, eliminating the need for repetitive client-side compilation.

Description

Technical Field

[0001] This invention relates to the field of information technology, and more specifically, to a method for dynamic extension of remote calls based on Java dynamic bytecode. Background Technology

[0002] In private cloud IaaS scenarios, to enable remote management of components within a VPC, an agent is typically installed on a designated cloud host within the VPC. The server then issues task commands to remotely invoke the designated agent, performing complex functions such as initiating HTTP calls to VPC components or reading / writing configuration files. The traditional approach uses a Java-based client / server architecture, where the server invokes remote access interfaces on the agent via application-layer protocols.

[0003] Currently, remote invocation implementations in the system are mainly divided into two types: shell scripting languages ​​and Java languages. Remote invocation tasks defined by shell scripts can be executed without compilation, but the implementation becomes very complex for complex calls such as HTTP requests, string processing, or scenarios involving Java language features. For remote calls with complex logic or those involving Java language features, it is necessary to write corresponding implementation code on both the calling and called ends, and then execute the remote call through the application layer protocol. This results in a large workload for development and maintenance, and poor scalability. Summary of the Invention

[0004] In view of this, the present invention provides a remote invocation dynamic extension method based on Java dynamic bytecode, which can use Java language features to define remote tasks, and can also be flexibly extended to improve development efficiency and reduce operation and maintenance costs.

[0005] On one hand, the present invention proposes a remote call dynamic extension method based on Java dynamic bytecode, comprising:

[0006] Based on the establishment of a C / S architecture, a communication channel is established between the client and the server. The server provides an interface for maintaining remote invocation tasks of Java source code type.

[0007] The interface defines remote tasks of Java source code type, and Javassist dynamically pre-compiles the Java source code into task bytecode and saves it on the server.

[0008] The server initiates a remote call to the specified client;

[0009] The client creates a custom ClassLoader to dynamically load task bytecode remotely from the server based on the task ID and version number, and then generates a Java class.

[0010] The client executes a method of the remote task object and returns the result of the call.

[0011] Furthermore, it also includes:

[0012] The client caches the bytecode of the remote call implementation class locally based on the remote call ID and version number to speed up program execution.

[0013] Furthermore, the client creates a custom ClassLoader to load the bytecode of the remote call implementation class from the server based on the task ID and version number parameters, then instantiates the remote call object through Java reflection and forcibly casts it to the agreed remote call interface.

[0014] Furthermore, the communication channel is that the client communicates with the server via a TCP long connection.

[0015] Furthermore, the server-side initiates a remote call to a specified client as follows:

[0016] The server initiates a remote call to the specified client using the remote call task ID, version number, and business data as parameters.

[0017] Furthermore, the server calls a specified task on the client through a remote call protocol at the application layer based on a TCP long connection, providing a general interface for the server to call a specified task on the client, and using the Gson tool name as the serialization / deserialization tool to process parameters and return values.

[0018] Furthermore, when saving remote call source code tasks, the server uses Javassist to dynamically compile them into bytecode files, using the task name and version number as class names, and the compiled bytecode is stored in the server's file system.

[0019] Furthermore, the server saves the version history of remotely called source code to the database for source code-level version control.

[0020] On the other hand, this invention also proposes a remote call dynamic extension system based on Java dynamic bytecode, comprising:

[0021] The server-side management console provides an interface based on a web management system for maintaining remote invocation tasks of Java source code types, and has CRUD (Create, Read, Update, Delete) functionality.

[0022] The server-side interface provides a web interface through which remote tasks are defined and managed.

[0023] The Javassist compiler dynamically compiles remote tasks of Java source code types defined through the server-side interface into bytecode, which will be stored on the server.

[0024] The Remote Procedure Call (RPC) protocol is an application-layer RPC protocol based on TCP long connections, used by the server to call a general interface for a specified task on the client. The RPC protocol uses Gson as a serialization / deserialization tool to process parameters and return values.

[0025] The remote call interface provides a defined remote call interface, including the remote call method, parameters, return value, and exception. Remote call tasks can only write implementation methods based on the remote call interface.

[0026] A custom ClassLoader, created by the client, dynamically loads the bytecode of the remote task from the server based on the ID and version number of the remote invocation task, and generates a Java class.

[0027] This invention provides a remote invocation dynamic extension method and system based on Java dynamic bytecode, which, compared with the prior art, has the following advantages:

[0028] This invention defines remote call tasks using Java source code, allowing for the use of Java language features to write complex call logic; it employs Java dynamic compilation technology, so it takes effect without compilation and deployment, achieving dynamic expansion; it implements source code-level version control for the remote call implementation, enabling flexible switching at runtime and mitigating online risks associated with dynamic expansion; the server compiles once, and multiple clients can run it, eliminating repetitive client compilation operations and avoiding the possibility of runtime compilation errors. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0030] Figure 1 This is a flowchart of a remote invocation dynamic extension method based on Java dynamic bytecode according to an embodiment of the present invention;

[0031] Figure 2 This is a functional block diagram of a remote call dynamic extension device based on Java dynamic bytecode according to an embodiment of the present invention. Detailed Implementation

[0032] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0034] See Figure 1-2 As shown, a preferred embodiment of the present invention provides a remote call dynamic extension method based on Java dynamic bytecode, comprising:

[0035] Based on the establishment of a C / S architecture, a communication channel is established between the client and the server. The server provides an interface for maintaining remote call tasks of Java source code type.

[0036] Remote tasks of Java source code type are defined through the interface, and Javassist is used to dynamically pre-compile the Java source code into task bytecode and save it on the server.

[0037] The server initiates a remote call to the specified client;

[0038] The client creates a custom ClassLoader to dynamically load task bytecode remotely from the server based on the task ID and version number, and then generates a Java class.

[0039] The client executes a method of the remote task object and returns the result of the call.

[0040] It should be noted that defining tasks using Java language features allows developers to define complex remote invocation tasks using the features of the Java programming language, including various libraries, frameworks, and functions provided by the Java programming language, making it easier to implement complex remote invocation logic. Through Javassist technology, Java source code-type remote tasks can be dynamically compiled into bytecode on the server side, eliminating the need for manual compilation and deployment, resulting in dynamic expansion and making the deployment and updates of new tasks more flexible. This embodiment provides a source-level version control mechanism, allowing switching between different versions of the task implementation at runtime. This helps mitigate potential online risks associated with dynamic expansion and allows the system to switch between different versions of the task. Using Java source code to define tasks simplifies the development of complex invocation logic. Furthermore, eliminating the need for manual task compilation and deployment reduces operational work and improves development and maintenance efficiency. The client creates a custom ClassLoader and dynamically loads the task bytecode, eliminating the need to send the task's source code to the client, helping to maintain client independence and reducing potential security risks. By establishing a C / S architecture communication channel and using a standard remote invocation protocol, this method provides a general remote invocation framework that can be used in various remote invocation scenarios.

[0041] In some embodiments, it also includes:

[0042] The client caches the bytecode of the remote call implementation class locally based on the remote call ID and version number to speed up program execution.

[0043] Understandably, the client maintains a local cache manager to store the bytecode of remote call tasks. This manager can use either memory caching or disk caching, depending on the number and size of the tasks. The client constructs a unique cache key based on the remote call ID and version number to retrieve the corresponding bytecode in the cache. Typically, the cache key can be constructed by concatenating the remote call ID and version number to ensure uniqueness. The client can employ cache eviction policies such as LRU (Least Recently Used) to ensure that cache space is occupied by frequently used tasks, reducing the cache priority of infrequently used tasks and improving the cache hit rate. Before initiating a remote call, the client first checks whether the bytecode corresponding to the remote call ID and version number exists in the local cache. If it exists, the client directly uses the bytecode in the local cache to instantiate the remote call object, avoiding the time and network overhead of reloading the bytecode from the server. When the server initiates a new remote call or updates the task version, the client needs to update the local cache accordingly. This can be done by periodically checking the server's task version information or by the server notifying the client to update the cache when the server's tasks change.

[0044] In some embodiments, the client creates a custom ClassLoader to load the bytecode of the remote call implementation class from the server based on the task ID and version number parameters, then instantiates the remote call object through Java reflection and forcibly casts it to the agreed remote call interface.

[0045] Understandably, the above can be implemented as follows: The client needs to create a custom ClassLoader to load the bytecode of the remote invocation task provided by the server. The ClassLoader can inherit from the java.lang.ClassLoader class and override the findClass method to use custom logic when loading bytecode.

[0046] Bytecode retrieval: The client requests the bytecode for a specific task from the server. Typically, this is done using HTTP or other network protocols to communicate and request the bytecode from the server. The server should respond to the client's request and return the bytecode data.

[0047] Custom ClassLoader for Bytecode Loading: A client-side custom ClassLoader retrieves bytecode data over the network and loads it using custom logic. The `defineClass` method can be used to load the bytecode and convert it into a Class object.

[0048] Instantiating a remote invocation object: The client instantiates the remote invocation object using Java reflection based on the obtained Class object. This can be done through the Class.newInstance() method or by invoking the constructor via reflection.

[0049] Interface casting: The client can cast the instantiated object to a pre-defined remote invocation interface, and the client can call the methods defined in the task interface.

[0050] In some embodiments, the communication channel is for the client to communicate with the server via a long TCP connection.

[0051] In some embodiments, the server initiates a remote call to a specified client as follows:

[0052] The server initiates a remote call to the specified client using the remote call task ID, version number, and business data as parameters.

[0053] It's important to note that TCP long connections enable clients and servers to establish bidirectional communication channels, allowing them to communicate at any time and enhancing the system's real-time performance and interactivity. The server can initiate remote call requests to specified clients at any time, enabling real-time triggering and execution of remote calls, which is particularly important in scenarios requiring immediate response, such as monitoring and alarms. By passing the remote call task ID, version number, and business data as parameters, the server can dynamically call the client based on the specific task and version number, achieving more flexible remote call logic. TCP long connections allow asynchronous communication, allowing clients and servers to process multiple requests in parallel, thereby improving system concurrency and performance. Because the communication channel is built on the TCP protocol, client and server connections can be easily expanded to meet ever-increasing communication demands. Long connections are more reliable in unstable network environments because connection maintenance can tolerate certain network fluctuations without requiring frequent re-establishment. If a connection is lost, the client and server can implement an automatic reconnection mechanism to ensure connection reliability.

[0054] In some embodiments, the server calls a specified task on the client through a remote invocation protocol at the application layer based on a long TCP connection, providing a general interface for the server to call a specified task on the client, and using the Gson tool name as the serialization / deserialization tool's processing parameters and return value.

[0055] Understandably, the above can be achieved by defining a remote invocation protocol interface: A protocol interface is shared between the server and client, defining the methods, parameters, return values, and exceptions that can be remotely invoked. This interface should contain all the information required for the remote invocation.

[0056] Serializing parameters and return values: On both the client and server sides, use Gson or a similar library to serialize method call parameters and deserialize return values. This ensures that data is encoded and decoded in a standard format when transmitted over the network.

[0057] Establishing a persistent TCP connection: Using Java's Socket programming, a persistent TCP connection is established between the server and the client to enable bidirectional communication.

[0058] The server should provide a generic interface to receive remote call requests. This interface should accept the requested method name, parameters, and other call information, and then execute the remote call logic according to the protocol definition.

[0059] Client calls server method: The client sends a remote call request to the server through an established TCP connection, and sends the method name and parameters to the server after serialization.

[0060] The server handles remote call requests: After receiving a request from the client, the server executes the corresponding method based on the method name and parameters in the request. Then, it serializes the method's return value and sends it back to the client.

[0061] Client receives and processes the result: The client receives the response from the server, deserializes it, obtains the return value of the method, and finally returns it to the caller.

[0062] Exception handling: If an exception occurs during the execution of a remote method, the exception information needs to be captured, serialized, and then passed to the client. The client then handles the exception based on the received exception information.

[0063] In some embodiments, when saving remote call source code tasks, the server uses Javassist to dynamically compile them into bytecode files, using the task name and version number as class names, and the compiled bytecode is stored in the server's file system.

[0064] In some embodiments, the server saves the version history of the remote call source code to the database for source code-level version control.

[0065] It's important to note the dynamic extensibility: using Javassist to dynamically compile source code allows new remote call tasks to be added to the system without recompiling the entire application, improving system scalability and allowing for the dynamic introduction of new features. By using task names and version numbers as class names, the server can prevent duplicate task names, allowing different versions of tasks to coexist. This allows the system to support multiple different versions of tasks, ensuring compatibility and smooth upgrades. Since dynamically compiled tasks do not require redeployment or recompiling the entire application, they take effect immediately at runtime. This allows developers to adjust remote call tasks more quickly without interrupting the running system. Saving the version history of the remote call source code to a database and implementing source-level version control allows the system to track the evolution of remote call tasks. This helps in understanding the modification history of each task version, facilitating troubleshooting and rollback to previous versions. By saving the version history of remote call tasks to a database, administrators can better manage and maintain different versions of tasks. This is crucial for system stability and maintainability. Source-level version control allows for flexible switching of task versions at runtime, mitigating online risks that dynamic expansion may introduce and ensuring system stability.

[0066] Preferably, this embodiment uses a C / S architecture framework developed based on the Netty framework. The client communicates with the server via a long TCP connection, and the server holds the client's session information. A remote invocation protocol at the application layer is implemented based on the long TCP connection, providing a general interface for the server to call specified tasks on the client. Gson tools are used as serialization / deserialization tools to process parameters and return values. The server's management console is a web management system developed using Spring Boot, MyBatis-Plus, and Vue. It provides an interface for maintaining remote invocation tasks of Java source code type, with CRUD (Create, Read, Update, Delete) functionality. The system provides a predefined remote invocation interface, including remote invocation methods, parameters, return values, and exceptions. Remote invocation tasks can only be implemented based on this interface. When saving remote invocation source code tasks, the server uses JavaScript... The system dynamically compiles the remote call source code into bytecode files, using the task name and version number as class names to avoid duplication. The compiled bytecode is stored in the server's file system. The server saves the version history of the remote call source code in the database and performs source-level version control. The server uses the remote task ID, version number, and business data as parameters to initiate a remote call to the specified client (based on the protocol in step 2). The client creates a custom ClassLoader to load the bytecode of the remote call implementation class from the server based on the task ID and version number parameters, then instantiates the remote call object through Java reflection and forcibly casts it to the agreed remote call interface. The client executes the interface method of the remote call object and then returns the call result to the server through the remote call protocol. The client caches the bytecode of the remote call implementation class locally based on the remote call ID and version number to speed up program execution.

[0067] On the other hand, embodiments of the present invention also provide a remote call dynamic extension system based on Java dynamic bytecode, comprising:

[0068] The server-side management console provides an interface based on a web management system for maintaining remote invocation tasks of Java source code types, and has CRUD (Create, Read, Update, Delete) functionality.

[0069] The server-side interface provides a web interface for defining and managing remote tasks.

[0070] The Javassist compiler, based on Javassist, dynamically compiles remote tasks of Java source code types defined through the server-side interface into bytecode, which will be stored on the server.

[0071] The Remote Procedure Call (RPC) protocol is an application-layer RPC protocol based on TCP long connections. It is used by the server to call a general interface for a specified task on the client. The RPC protocol uses Gson as a serialization / deserialization tool to process parameters and return values.

[0072] The remote call interface provides a defined remote call interface, including the remote call method, parameters, return value, and exception. Remote call tasks can only write implementation methods based on the remote call interface.

[0073] A custom ClassLoader, created by the client, dynamically loads the bytecode of the remote task from the server based on the ID and version number of the remote invocation task, and generates a Java class.

[0074] Specifically, such as Figure 2 As shown, the server responsible for task management has the following functions: task definition, task testing, task compilation, version control, task publishing, and remote invocation; the client responsible for task execution has the following functions: task update, task loading, task caching, and task execution.

[0075] It's worth noting that this system allows for the dynamic addition, modification, and deletion of remote invocation tasks at runtime without recompiling or deploying the entire application. This provides significant flexibility and dynamic scalability, allowing the system to adapt to changing needs. A web interface allows developers and administrators to easily manage and configure remote invocation tasks, including defining, editing, deleting, and querying tasks. This simplifies task management and reduces development and maintenance complexity. A custom ClassLoader loads remote task bytecode from the server based on the task's ID and version number. The client instantiates remote invocation objects via Java reflection, offering higher performance because local bytecode execution is faster than other methods. Using Gson as the serialization / deserialization tool for handling parameters and return values ​​makes data transmission more efficient and allows different versions of tasks to communicate using the same protocol. By providing a remote invocation interface, the methods, parameters, return values, and exceptions of remote invocation tasks are defined, ensuring task consistency and interoperability. Version control allows the system to maintain a history of different task versions, aiding in troubleshooting, rollback, and maintenance. The server-side management console provides a user-friendly interface based on a web-based management system, making task creation and management easier. Administrators can easily view, modify, and monitor tasks. Source-level version control allows for flexible switching of task versions at runtime, thus mitigating online risks that dynamic scaling may introduce and ensuring system stability.

[0076] The above description is merely one embodiment of the present invention, but it cannot be used to limit the scope of the present invention. Any structural changes made based on the present invention, as long as they do not lose the essence of the present invention, should be considered to fall within the protection scope of the present invention and be subject to its restrictions.

[0077] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of the present invention can be further decomposed or combined. For example, the modules in the above embodiments can be merged into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of the present invention are only for distinguishing the various modules or steps and are not considered as an improper limitation of the present invention.

[0078] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0079] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after such changes or substitutions will all fall within the scope of protection of the present invention.

[0080] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention.

Claims

1. A method for dynamically extending remote calls based on Java dynamic bytecode, characterized in that, include: Based on the establishment of a C / S architecture, a communication channel is established between the client and the server. The server provides an interface for maintaining remote invocation tasks of Java source code type. The interface defines remote invocation tasks of Java source code type. Java source code is dynamically pre-compiled into task bytecode by Javassist and stored on the server. The server initiates a remote call to the specified client; The client creates a custom ClassLoader to dynamically load task bytecode remotely from the server based on the task ID and version number, and then generates a Java class. The client executes a method of the remote call task object and returns the call result; Also includes: The client caches the bytecode of the remote call implementation class locally based on the remote call ID and version number to speed up program execution. The client creates a custom ClassLoader, loads the bytecode of the remote call implementation class from the server based on the task ID and version number parameters, then instantiates the remote call object through Java reflection and forcibly casts it to the agreed remote call interface; When saving remote call source code tasks, the server uses Javassist to dynamically compile them into bytecode files, using the task name and version number as class names, and the compiled bytecode is stored in the server's file system. The server saves the version history of remotely called source code to the database, performing source code-level version control.

2. The remote call dynamic extension method based on Java dynamic bytecode according to claim 1, characterized in that, The communication channel is that the client communicates with the server via a TCP long connection.

3. The remote call dynamic extension method based on Java dynamic bytecode according to claim 1, characterized in that, The server initiates a remote call to a specified client as follows: The server initiates a remote call to the specified client using the remote call task ID, version number, and business data as parameters.

4. The remote call dynamic extension method based on Java dynamic bytecode according to claim 3, characterized in that, The server calls a specified task on the client through a remote call protocol implemented at the application layer based on a TCP long connection. It provides a general interface for the server to call a specified task on the client and uses the Gson tool name as the parameter and return value for the serialization / deserialization tool.

5. A remote invocation dynamic extension system based on Java dynamic bytecode, characterized in that, include: The server-side management console provides an interface based on a web management system for maintaining remote invocation tasks of Java source code types, and has CRUD (Create, Read, Update, Delete) functionality. The server-side interface provides a web interface through which remote invocation tasks are defined and managed. The Javassist compiler dynamically compiles remote call tasks of Java source code types defined through the server-side interface into bytecode, which will be stored on the server. Remote Procedure Call (RPC) protocol, an application-layer RPC protocol based on TCP long connections, is used for the server to call a general interface for a specified task on the client. The remote procedure call protocol uses Gson as a serialization / deserialization tool to process parameters and return values; The remote call interface provides a defined remote call interface, including the remote call method, parameters, return value, and exception. Remote call tasks can only write implementation methods based on the remote call interface. A custom ClassLoader is created by the client. It dynamically loads the bytecode of the remote invocation task from the server based on the ID and version number of the remote invocation task and generates a Java class.

6. An application of the remote call dynamic extension method based on Java dynamic bytecode as described in any one of claims 1-4 in the field of cloud host monitoring and maintenance infrastructure components.

Images