WO2024212612A1 - Remote invocation dynamic extension method based on dynamic java bytecode - Google Patents

Abstract

The present invention relates to the field of information technology, and relates specifically to a remote invocation dynamic extension method and system based on a dynamic Java bytecode. The method comprises: a client and a server establish a communication channel on the basis of an established C/S architecture, and the server provides an interface, the interface being used for maintaining Java source code remote invocation tasks; Java source code remote tasks are defined by means of the interface, and Java source code is dynamically precompiled into task bytecode by means of Javassist and stored on the server; the server uses the remote invocation task ID, the version number, and the service data as parameters to initiate remote invocation for a specific client; the client creates a user-defined ClassLoader, remotely loads the task bytecode from the server, and generates a Java class; and the client executes a method of the remote task object and returns an invocation result. In the present invention, a single instance of compilation is carried out, multiple client ends are in operation, and repeated client compilation operations are eliminated.

Description

A remote call dynamic extension method based on Java dynamic bytecode Technical Field

The present invention relates to the field of information technology, and in particular to a remote call dynamic expansion method based on Java dynamic bytecode.

Background Art

In the private cloud IaaS scenario, in order to achieve remote management of vpc internal components, an agent is usually installed on the specified cloud host in the vpc, and then the server sends task instructions to implement remote calls to the specified agent, such as initiating HTTP calls to vpc internal components or reading and writing configuration files and other complex functions. The traditional solution is a C/S architecture implemented in Java language, and the server calls the remote call interface on the agent through the application layer protocol.

Currently, the implementation of remote calls in the system is mainly divided into two types: shell script language and Java language: remote call tasks defined by shell scripts can be executed without compilation, but for complex calls such as http requests and string processing or scenarios containing Java language features, the implementation will be very complicated. For remote calls with complex logic or containing Java language features, it is necessary to write supporting implementation codes on both the calling and called ends, and then execute remote calls through application layer protocols. There are problems such as large development and operation workload and poor scalability.

Summary of the invention

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

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

Based on the establishment of C/S architecture, a communication channel is established between the client and the server. Providing an interface for maintaining a remote call task of a Java source code type;

Define a remote task of Java source code type through the interface, dynamically precompile the Java source code into task bytecode through Javassist, and save it on the server;

The server initiates a remote call to the specified client;

The client creates a custom ClassLoader, dynamically loads the task bytecode remotely from the server based on the task ID and version number, and generates a Java class;

The client executes the method of the remote task object and returns the call result.

Furthermore, it 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 the program running efficiency.

Furthermore, the client creates a custom ClassLoader to load the bytecode of the remote call implementation class from the server according to the task ID and version number parameters, and then instantiates the remote call object through the Java reflection mechanism and forces it to be transformed into the agreed remote call interface.

Furthermore, the communication channel is for the client to communicate with the server through a TCP long connection.

Furthermore, the server initiates a remote call to the 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.

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

Furthermore, when saving a remote call source code task, the server uses Javassist to dynamically compile it into a bytecode file, uses the task name and version number as the class name, and stores the compiled bytecode in the server file system.

Furthermore, the server saves the version history of the remote call source code to the database to perform source code level version control.

On the other hand, the present invention also proposes a remote call dynamic expansion system based on Java dynamic bytecode, comprising:

The server management console provides an interface based on the Web management system for maintaining remote call tasks of Java source code type, and has the functions of adding, deleting, modifying and checking;

A server interface, providing a web interface, through which remote tasks are defined and managed;

Javassist compiler, based on Javassist, dynamically compiles remote tasks of Java source code type defined through the server interface into bytecode, and the bytecode will be stored on the server;

Remote call protocol, which implements the application layer remote call protocol based on TCP long connection, and is used by the server to call the general interface of the specified task on the client; the remote call protocol uses Gson as a serialization/deserialization tool to process parameters and return values;

Remote call interface, which provides the agreed remote call interface, including the remote call method, parameters, return value and exception. The remote call task can only be implemented by writing the implementation method based on the remote call interface;

The custom ClassLoader is created by the client, dynamically loads the remote task bytecode from the server according to the ID and version number of the remote call task, and generates a Java class.

The embodiment of the present invention provides a remote call dynamic extension method and system based on Java dynamic bytecode, which has the following beneficial effects compared with the prior art:

The present invention defines remote call tasks through Java source code, and can use Java language characteristics to write complex call logic; uses Java dynamic compilation technology, so it can take effect without compilation and deployment, and can achieve the effect of dynamic expansion; performs source code level version control on remote call implementation, and can be flexibly switched at runtime, avoiding online risks brought by dynamic expansion; the server compiles once and the client runs on multiple terminals, eliminating repeated client compilation operations and avoiding the possibility of compilation errors at runtime.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

1 is a flow chart of a remote call dynamic extension method based on Java dynamic bytecode according to an embodiment of the present invention;

FIG. 2 is a functional block diagram of a remote call dynamic expansion device based on Java dynamic bytecode according to an embodiment of the present invention.

DETAILED DESCRIPTION

The technical solutions in the embodiments of the present invention are described clearly and completely below. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

In the description of this application, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to specific circumstances.

Referring to FIG. 1-2 , a remote call dynamic extension method based on Java dynamic bytecode according to a preferred embodiment of the present invention includes:

Based on the establishment of C/S architecture, a communication channel is established between the client and the server. The server provides an interface, which is used to maintain remote call tasks of Java source code type;

Define remote tasks of Java source code type through the interface, dynamically pre-compile Java source code into task bytecode through Javassist, and save it on the server;

The server initiates a remote call to the specified client;

The client creates a custom ClassLoader, dynamically loads the task bytecode remotely from the server based on the task ID and version number, and generates a Java class;

The client executes the method of the remote task object and returns the call result.

It should be noted that the method of defining tasks using Java language features allows developers to use the features of the Java programming language to define complex remote call tasks, including various libraries, frameworks, and functions provided by the Java programming language, making it easier to implement complex remote call logic; through Javassist technology, Java source code type remote tasks can be dynamically compiled into bytecode on the server side without manual compilation and deployment, bringing dynamic expansion effects. The result is that the deployment and update of new tasks are more flexible; the method of this embodiment provides a version control mechanism at the source code level, allowing different versions of task implementations to be switched at runtime. This helps to avoid online risks that may be caused by dynamic expansion, while allowing the system to switch between different versions of tasks; using Java source code to define tasks simplifies the development of complex calling logic. In addition, there is no need to manually compile and deploy tasks, which reduces operation and maintenance work and improves development and maintenance efficiency; the client creates a custom ClassLoader and dynamically loads the task bytecode, without sending the source code of the task to the client, which helps maintain the independence of the client and reduces potential security risks; by establishing a C/S architecture communication channel and using a standard remote call protocol, the method provides a general remote call framework that can be used in a variety of remote call scenarios.

In some embodiments, it 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 the program running efficiency.

It is understood that the client maintains a local cache manager to store the bytecode of the remote call task. This manager can use memory cache or disk cache, depending on the number and size of tasks. The client builds a unique cache key based on the remote call ID and version number to retrieve the corresponding bytecode in the cache. Usually, the cache key can be concatenated with the remote call ID and version number to ensure uniqueness. The client can use cache elimination strategies such as LRU (Least Recently Used) to ensure that the cache space is occupied by frequently used tasks, reduce the cache priority of infrequently used tasks, and improve the cache hit rate. Before initiating a remote call, the client first checks whether there is bytecode corresponding to the remote call ID and version number in the local cache. If it exists, the bytecode in the local cache is directly used to instantiate the remote call object, avoiding the time and network overhead of loading the bytecode again from the server. When the server initiates a new remote call or updates the version of the task, the client needs to update the local cache accordingly. The cache can be updated by regularly checking the task version information on the server, or by notifying the client when the server task changes.

In some embodiments, the client creates a custom ClassLoader to load the bytecode of the remote call implementation class from the server according to the task ID and version number parameters, and then uses Java The reflection mechanism instantiates the remote call object and forces it to be transformed into the agreed remote call interface.

It is understandable that the above content can be implemented in the following ways: Creation of a custom ClassLoader on the client: The client needs to create a custom ClassLoader to load the bytecode of the remote call task provided by the server. ClassLoader can inherit from the java.lang.ClassLoader class and override the findClass method to use custom logic when loading bytecode.

Obtaining bytecode: The client requests the server to obtain the bytecode for a specific task. Usually, HTTP or other network protocols can be used for communication to request the server to provide the bytecode for the task. The server should respond to the client's request and return the bytecode data.

Custom ClassLoader loads bytecode: After the client's custom ClassLoader obtains the bytecode data through the network, it uses custom logic to load the bytecode. You can use the defineClass method to load the bytecode and convert it into a Class object.

Instantiate remote call object: The client uses the Java reflection mechanism to instantiate the remote call object based on the obtained Class object. This can be done through the Class.newInstance() method or by calling the constructor through reflection.

Interface forced transformation: The client can force the instantiated object to be transformed into the agreed remote call interface, and the client can call the methods defined in the task interface.

In some of the embodiments, the communication channel is that the client communicates with the server through a TCP long connection.

In some embodiments, 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.

It should be noted that through TCP persistent connection, the client and server can establish a two-way communication channel, so that both parties can communicate at any time, enhancing the real-time and interactive nature of the system. The server can initiate a remote call request to the specified client at any time, so that the remote call can be triggered and executed in real time, which is particularly important in scenarios that require immediate response, such as monitoring and alarming. By passing the remote call task ID, version number, and business data as parameters, the server can dynamically call the client according to the specific task and version number, achieving more Add flexible remote call logic. TCP long connection allows asynchronous communication, and the client and server can process multiple requests in parallel, thereby improving the concurrency and performance of the system. Since the communication channel is built on the TCP protocol, the client and server connections can be easily expanded to meet the growing communication needs. Long connection is more reliable in an unstable network environment because the maintenance of the connection can tolerate certain network fluctuations without the need to frequently re-establish the connection. If the connection is disconnected, the client and server can implement an automatic reconnection mechanism to ensure the reliability of the connection.

In some of the embodiments, the server calls a specified task on the client by implementing a remote call protocol at the application layer based on a TCP long connection, provides a general interface for the server to call the specified task on the client, and uses the Gson tool name as a serialization/deserialization tool to process parameters and return values.

It is understandable that the above can be achieved in the following ways: Define a remote call protocol interface: Share a protocol interface between the server and the client, which defines the methods, parameters, return values and exceptions that can be called remotely. This interface should contain all the information required for remote calls.

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

Establish a TCP persistent connection: Use Java Socket programming to establish a persistent TCP persistent connection between the server and the client to achieve two-way communication.

The server provides a common interface: The server should provide a common interface for receiving remote call requests. This interface can accept the method name, parameters and other call information of the request, and then execute the logic of the remote call according to the protocol definition.

The client calls the server method: The client sends a remote call request to the server through the established TCP connection, and serializes the method name and parameters and sends them to the server.

The server processes the remote call request: After receiving the client's request, the server executes the corresponding method according to the method name and parameters in the request. Then the return value of the method is serialized and sent back to the client.

Client receives and processes the result: The client receives the response from the server and responds to it. Serialize, get the return value of the method, and finally return it to the caller.

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

In some of the embodiments, when saving a remote call source code task, the server uses Javassist to dynamically compile it into a bytecode file, uses the task name and version number as the class name, and stores the compiled bytecode in the server file system.

In some of the embodiments, the server saves the version history of the remote call source code to a database to perform source code level version control.

It should be noted that dynamic scalability: Using Javassist to dynamically compile source code allows new remote call tasks to be added to the system without recompiling the entire application, which improves the scalability of the system and allows new features to be introduced dynamically. By using the task name and version number as the class name, the server can prevent duplicate task names so that tasks of different versions can coexist. This allows multiple different versions of tasks to be supported in the system, ensuring compatibility and smooth upgrades. Since there is no need to redeploy or compile the entire application, dynamically compiled tasks can take effect immediately at runtime. This allows developers to adjust remote call tasks more quickly without interrupting the running system. The version history of the remote call source code is saved to the database, and source code-level version control is performed, so that the system can track the evolution of remote call tasks. This helps to understand the modification records of each task version, facilitates troubleshooting and rollback to previous versions. By saving the history of remote call task versions to the database, administrators can better manage and maintain different versions of tasks. This is very important for the stability and maintainability of the system. Source code-level version control allows flexible switching of task versions at runtime, thereby avoiding online risks that may be introduced by dynamic expansion and ensuring the stability of the system.

Preferably, this embodiment develops a basic framework of C/S architecture based on Netty framework. The client communicates with the server through TCP long connection, and the server holds the client's session information. A set of application layer remote call protocols is implemented based on TCP long connection, providing a general interface for the server to call the specified task on the client, and using Gson tool name as the serialization/deserialization tool to process parameters and return values; the management console of the server adopts The WEB management system developed by springboot+mybatis-plus+vue provides an interface for maintaining remote call tasks of Java source code type, with the functions of adding, deleting, modifying and checking; the system provides an agreed remote call interface, including remote call methods, parameters, return values and exceptions, and remote call tasks can only be implemented based on this interface; when saving remote call source code tasks, the server will use Javassist to dynamically compile them into bytecode files, use the task name and version number as the class name to avoid duplication, and store the compiled bytecode in the server file system; the server saves the version history of the remote call source code to the database, It performs version control at the source code level; 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 2); the client creates a custom ClassLoader to load the bytecode of the remote call implementation class from the server according to the task ID and version number parameters, and then instantiates the remote call object through the Java reflection mechanism and forces it to transform into 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 according to the remote call ID and version number to speed up the program running efficiency.

On the other hand, an embodiment of the present invention further provides a remote call dynamic expansion system based on Java dynamic bytecode, comprising:

The server management console provides an interface based on the Web management system for maintaining remote call tasks of Java source code type, and has the functions of adding, deleting, modifying and checking;

The server interface provides a web interface for defining and managing remote tasks;

Javassist compiler, based on Javassist, dynamically compiles remote tasks of Java source code type defined through the server interface into bytecode, which will be saved on the server;

Remote call protocol, which implements the application layer remote call protocol based on TCP long connection, is a general interface for the server to call the specified task on the client; the remote call protocol uses Gson as a serialization/deserialization tool to process parameters and return values;

Remote call interface, which provides the agreed remote call interface, including the remote call method, parameters, return value and exception. The remote call task can only be implemented by writing the implementation method based on the remote call interface.

The custom ClassLoader is created by the client, dynamically loads the remote task bytecode from the server according to the ID and version number of the remote call task, and generates a Java class.

Specifically, as shown in Figure 2, the server responsible for task management has the following functions: task definition, task testing, task compilation, version control, task publishing and remote calling; the client responsible for task execution has the following functions: task update, task loading, task caching and task execution.

It should be noted that the system allows remote call tasks to be dynamically added, modified, and deleted at runtime without recompiling or deploying the entire application. This provides great flexibility and dynamic scalability, allowing the system to change as needs change. By providing a web interface, developers and administrators can easily manage and configure remote call tasks, including defining, editing, deleting, and querying tasks. This simplifies the task management process and reduces the complexity of development and maintenance. Custom ClassLoader can load remote task bytecode from the server based on the task ID and version number. The client instantiates the remote call object through the Java reflection mechanism, which provides higher performance because the local execution of bytecode is faster than other methods. Using Gson as a serialization/deserialization tool to handle 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 call interface, the methods, parameters, return values, and exceptions of remote call tasks are agreed upon, thereby ensuring the consistency and interoperability of tasks. Version control allows the system to maintain a history of different task versions, which helps troubleshooting, rollback, and maintenance. The management console on the server provides a user-friendly interface based on the web management system, making it easier to create and manage tasks. Administrators can easily view, modify, and monitor tasks. Source code-level version control allows flexible switching of task versions at runtime, thereby avoiding online risks that may be introduced by dynamic expansion and ensuring system stability.

The above is only an example of implementation of the present invention, but it cannot be used to limit the scope of the present invention. Any structural changes made according to the present invention should be regarded as falling within the protection scope of the present invention and subject to restrictions as long as they do not lose the essence of the present invention.

It should be noted that the system provided in the above embodiment is only illustrated by the division of the above functional modules. In actual 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 decomposed or combined. For example, the modules in the above embodiment can be combined 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 each module or step and are not to be regarded as improper limitations of the present invention.

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

So far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle 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 these changes or substitutions will fall within the protection scope of the present invention.

The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention.

Claims (10)

A remote call dynamic extension method based on Java dynamic bytecode, characterized by comprising: Based on the establishment of C/S architecture, a communication channel is established between the client and the server, and the server provides an interface for maintaining remote call tasks of Java source code type; Define a remote task of Java source code type through the interface, dynamically precompile the Java source code into task bytecode through Javassist, and save it on the server; The server initiates a remote call to the specified client; The client creates a custom ClassLoader, dynamically loads the task bytecode remotely from the server based on the task ID and version number, and generates a Java class; The client executes the method of the remote task object and returns the call result. The remote call dynamic extension method based on Java dynamic bytecode according to claim 1 is characterized in that it 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 the program running efficiency. According to the remote call dynamic extension method based on Java dynamic bytecode as described in claim 2, it is characterized in that the client creates a custom ClassLoader to load the bytecode of the remote call implementation class from the server according to the task ID and version number parameters, and then instantiates the remote call object through the Java reflection mechanism, and forcibly transforms it into the agreed remote call interface. The remote call dynamic expansion method based on Java dynamic bytecode according to claim 1 is characterized in that the communication channel is that the client communicates with the server through a TCP long connection. According to the remote call dynamic extension method based on Java dynamic bytecode according to claim 1, it is characterized in that the server initiates the remote call to the specified client specifically 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. The remote call dynamic expansion method based on Java dynamic bytecode according to claim 5 is characterized in that the server calls the specified task on the client through a TCP long The connection implements the remote call protocol of the application layer, provides a common interface for the server to call the specified task on the client, and uses the Gson tool name as the serialization/deserialization tool to process parameters and return values. According to the remote call dynamic extension method based on Java dynamic bytecode as described in claim 1, it is characterized in that when saving the remote call source code task, the server uses Javassist to dynamically compile it into a bytecode file, uses the task name and version number as the class name, and stores the compiled bytecode in the server file system. According to the remote call dynamic expansion method based on Java dynamic bytecode according to claim 1, it is characterized in that the server saves the version history of the remote call source code to the database to perform version control at the source code level. A remote call dynamic expansion system based on Java dynamic bytecode, characterized by comprising: The server management console provides an interface based on the Web management system for maintaining remote call tasks of Java source code type, and has the functions of adding, deleting, modifying and checking; A server interface, providing a web interface, through which remote tasks are defined and managed; Javassist compiler, based on Javassist, dynamically compiles remote tasks of Java source code type defined through the server interface into bytecode, and the bytecode will be stored on the server; Remote call protocol, which implements the application layer remote call protocol based on TCP long connection, and is used by the server to call the general interface of the specified task on the client; the remote call protocol uses Gson as a serialization/deserialization tool to process parameters and return values; Remote call interface, which provides the agreed remote call interface, including the remote call method, parameters, return value and exception. The remote call task can only be implemented by writing the implementation method based on the remote call interface; The custom ClassLoader is created by the client, dynamically loads the remote task bytecode from the server according to the ID and version number of the remote call task, and generates a Java class. An application of the remote call dynamic extension method based on Java dynamic bytecode as described in any one of claims 1 to 8 in the field of cloud host monitoring and operation and maintenance basic components.