WO2009129732A1

WO2009129732A1 - A distributed message invoking method and device

Info

Publication number: WO2009129732A1
Application number: PCT/CN2009/071364
Authority: WO
Inventors: 申海; 李战杰; 丁凯
Original assignee: 华为技术有限公司
Priority date: 2008-04-22
Filing date: 2009-04-20
Publication date: 2009-10-29
Also published as: CN101262498B; CN101262498A

Abstract

A distributed message invoking method and device are provided. The method includes the following steps: transmitting an invoke request message by an asynchronous invoke mode in the method body (21); preserving the invoke stack information of the invoke request message and of the current running state, and quitting the method body (22). When the response message of the invoke request message is received, resuming the preserved invoke stack information (23). The running state current before the method body was quit is then resumed according to the resumed invoke stack information, and performance of the subsequent logic (24) is continued.

Description

Method and device for distributed call message

The present application claims priority to Chinese Patent Application No. 200810094611.1, entitled "A Method and Apparatus for Distributed Calling Messages", filed on April 22, 2008, the entire contents of In this application.

Technical field

The present invention relates to the field of communications technologies, and in particular, to a method and apparatus for distributed call messages. Background technique

The soft bus technology provides cross-platform, 3fi, and component communication capabilities, which can solve the problem of system distribution and scalability, and is the basis for implementing a distributed message processing platform. At present, there are three influential soft bus specifications in the industry: Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), and Java2 Platform Enterprise. Edition (J2EE, Java 2 Platform, Enterprise Edition). Among them, CORBA is a standard object-oriented application system specification developed by the Object Management Government (OMG). DCOM is proposed by Microsoft to support communication between objects on different computers in the LAN, WAN, and even the Internet. J2EE is a distributed object bus standard proposed by SUN. The following is a brief introduction to CORBA as an example of how to invoke messages under a distributed platform.

When a client wants to use an object to implement the provided service, the general process is as follows: 1) The client finds an object reference of a specific object in some way;

2) If the object implementation has a corresponding interface definition language (IDL, Interface Definition

Language), the client can make a request to the object implementation through the IDL stub, otherwise, with the assistance of the interface library, the client can use the dynamic call interface to send a request to the object implementation;

3) After the object call request reaches the core of the Object Request Broker (ORB) through the IDL stub or the dynamic call interface, the ORB core is responsible for the transfer of the request and transmits it to the corresponding object adapter;

4) After receiving the request, the object adapter determines whether the requested object implementation has an IDL skeleton, and if so, the object adapter invokes an operation performed by the object through the IDL skeleton; otherwise, the object adapter passes through the dynamic skeleton interface. Dynamically implement routines to invoke operations in object implementations;

5) The specific operation method of the object implementation After the method is executed, the result will be according to the object. The request delivery and execution paths are returned back to the client object. The result can be output parameters, input and output parameters, return values, and exception information.

In general, distributed calls are divided into two ways: asynchronous calls and synchronous calls. For asynchronous calls, the result is not immediately available after the call, and the subsequent logic is not blocked but the subsequent logic is continued. Asynchronous calls are useful for situations where you don't immediately care about the result of the call or make a batch of unrelated calls in succession. For synchronous calls, subsequent logic is blocked when called, until the call completes the result or the call times out.

In general, developers are more comfortable with synchronous calls, which seems to be as convenient as local calls, but because distributed remote calls cannot get results as immediately as local calls, they block the thread until they get results or timeouts, which inevitably affects the call. performance.

If you want to improve the processing performance of the system, you need to use the asynchronous call mode. When defining the IDL, you need to define two one-way operations, one for invoking the call and one for sending the result, which are implemented by the calling parties respectively, and are used by the client. And server-side calls.

In the research and practice of the prior art, the inventors of the present invention found that in the prior art, for an asynchronous call, the user cannot get the return value immediately after the call, and only calls the call when the call is made, and the call result needs to be additionally A place to receive and process, this development method to some extent disrupted the program logic, increased the difficulty and cost of development, and reduced program readability and maintainability. For application development, the development efficiency of using synchronous calls is much higher than that of asynchronous methods, but the synchronous calling of traditional distributed systems requires thread blocking. For large concurrent communication systems, limited thread resources and high-cost lock operations. Will greatly affect the processing performance. In summary, in the prior art distributed call message method, system processing performance and service development efficiency cannot be balanced.

Summary of the invention

The technical problem to be solved by the embodiments of the present invention is to provide a method and device for distributing messages in a distributed manner, which can balance system processing performance and service development efficiency.

To solve the above technical problem, the method and apparatus for distributed call message provided by the present invention are implemented by the following technical solutions:

An embodiment of the present invention provides a method for distributedly invoking a message, where the method includes: sending an invocation request message in an asynchronous manner within a method body;

Saving the call stack information of the call request message and the current running state and exiting the method body; When the response message of the call request message is received, the saved call stack information is restored; according to the restored call stack information, the running state before exiting the method body is restored, and the subsequent logic is continued.

An embodiment of the present invention provides a distributed processing apparatus, where the apparatus includes: a message invoking unit and an information processing unit, where:

The message invoking unit includes: a message sending unit, a message receiving unit, an information storage unit, and a stack information maintaining unit, where:

The message sending unit sends the call request message in an asynchronous manner in the method body; the message receiving unit receives the response message of the call request message;

An information storage unit, configured to save call stack information and a current running state of the method body;

a stack information maintenance unit, when the message sending unit sends the call request message, saves the call stack information and the current running state of the call request message to the information storage unit and exits the method body; and receives a response message at the message receiving unit When the call stack information saved in the information storage unit is restored;

The information processing unit resumes the running state before exiting the method body according to the call stack information recovered by the stack information maintenance unit, and continues to execute the subsequent logic.

As can be seen from the above technical solution, the embodiment of the present invention sends an invocation request message by using an asynchronous call in the method body. During the waiting for the response, the thread is not blocked, and other services can be processed, so that the processing performance of the system can be guaranteed; When the response message of the call request message is received, since the restored stack information can be directly restored to the running state before exiting the method body, and the subsequent logic is continued, the subsequent logic can directly apply the current method body. The result of the call, for the developer, the asynchronous call is encapsulated inside the method body, only the processing of the method body and the sequential execution of the subsequent logic are seen, just like the synchronous call, therefore, the complexity of the business development can be reduced. Improve business development efficiency. In summary, the technical solution described in the embodiments of the present invention can simultaneously consider the processing performance and service development efficiency of the system.

DRAWINGS

1 is a schematic structural diagram of an embodiment of a distributed processing apparatus according to an embodiment of the present invention;

2 is a flowchart of an embodiment of a method for distributedly calling a message according to an embodiment of the present invention;

3 is a flowchart of an asynchronous call in an embodiment of the present invention; Figure 4 is a state diagram of an embodiment of the present invention.

detailed description

The embodiment of the invention provides a method and a device for distributing messages in a distributed manner, which can simultaneously consider the processing performance and service development efficiency of the system. To enable those skilled in the art to better understand and implement the embodiments of the present invention,

1 is a schematic structural diagram of an embodiment of a distributed processing apparatus according to an embodiment of the present invention. The distributed processing apparatus includes: a message invoking unit 11 and an information processing unit 12, where:

The message invoking unit 11 includes: a message transmitting unit 111, a message receiving unit 112, an information storage unit 113, and a stack information maintaining unit 114, wherein:

The message sending unit 111 sends an invocation request message in an asynchronous manner inside the method body;

The message receiving unit 112 receives the response message of the call request message;

The information storage unit 113 stores the call stack information and the current running state of the method body; the stack information maintaining unit 114, when the message sending unit 111 sends the call request message, the call stack information of the call request message and the current running state. Save to the information storage unit 113 and exit the method body; when the message receiving unit 112 receives the response message, restore the call stack information stored in the information storage unit 113;

The information processing unit 12 resumes the running state before exiting the method body according to the call stack information recovered by the stack information maintenance unit 114, and continues to execute the subsequent logic.

The call stack information and the call request message saved by the information processing unit, correspondingly, may set a correspondence between the call request message identifier and the call stack information, and the response message returned by the message receiving unit carries an identifier consistent with the call request message. In order to enable the stack information maintenance unit to quickly find the saved call stack information and recover.

The subsequent processing logic of the information processing unit may be subsequent normal logic, timeout processing logic, or exception processing logic, corresponding to the service call result carried by the response message received by the message receiving unit.

It can be understood that the distributed processing device does not represent a specific device name and is only used to indicate a device that can be used for distributed processing. Such distributed processing devices are widely used in any distributed processing system, such as computers, networks, and distributed processing devices. For such a distributed processing device, other remote services can be called by the message invoking unit, specify the called object and the called method body, set the calling parameters, etc., migrate through the message driving state, and call the message unit before the migration. The return result has been received, and the information processing unit can directly utilize the returned result. Therefore, from the perspective of the use experience, the asynchronous call is encapsulated inside the method body, and the developer sees only the processing of the method body and the sequential execution of the subsequent logic. It is exactly the same as the synchronous call, so the message calling mode of the distributed processing device is more friendly to the developer, which can reduce the complexity of business development and improve the efficiency of business development. In the message invoking unit, the message is invoked in an asynchronous manner. During the waiting for the message to be acknowledged, the thread will not be blocked and can continue to process other services, so that the processing performance of the system can also be guaranteed. In summary, this distributed processing device can not only improve the efficiency of business development, but also balance the processing performance of the system.

Referring to FIG. 2, a flow chart of a method embodiment of a distributed call message is described below by a specific calling process in the method body F1:

Step 21: Send a foo call request message in the method body F1 by using an asynchronous call mode and execute step 22;

The method body is a member of the class and is a function associated with the class, which can access the elements in the class.

For the above asynchronous calling mode, referring to FIG. 3, it is a flowchart of asynchronous calling in the embodiment of the present invention. The specific process of performing one-to-one asynchronous calling in a distributed system is as follows:

Step 211: The caller initiates a call request to the callee.

After the caller initiates the call, the subsequent logic continues.

Step 212: The callee performs processing after receiving the request;

Step 213: The callee initiates a call request, where the result obtained by processing the caller request is carried.

Step 214: The caller receives the call request of the callee, performs processing, and obtains a processing result. Step 22: save the call stack information of the foo call request message and the current running state and exit the method body F1;

The call stack information and the current running state are saved before exiting the method body F1, and then the current thread is released, after which the thread can continue to process other calls to ensure the processing performance of the system.

Step 23: After receiving the response message of the foo call request message, restoring the saved call stack letter Step 24: According to the restored call stack information, return to the running state before exiting the F1 method body, and continue to perform subsequent resuming.

After the scheduling thread re-schedules into the method body F1 according to the restored call stack information, the subsequent logic is executed from the running state before the method body F1 is exited until the method body F1 ends logically and exits the method body F1.

Since the subsequent logic can directly use the result of the call returned in the response message in step 23, from the developer's point of view, the same as the synchronous call mode, the business logic does not need to be disrupted, so the complexity of the business development can be reduced, and the business development can be improved. effectiveness.

In order to quickly find the saved call stack information and quickly return to the running state before exiting the method body F1, the correspondence between the call stack information and the call request message and the call response message may be set, specifically: preset The identifier of the call request message has the same identifier (ID, Identification) as the response message corresponding to the request message, and the ID of the call request message corresponding to the call stack information is saved while the call stack information is saved, when the call is received. When requesting the response message of the message, the call stack information having the same ID as the response message is searched, and then the call stack information is restored and the running state before the method body is exited, and the subsequent logic is executed.

For ease of understanding, this method can describe the logic of the application service using a state diagram, which can define a series of states that are migrated by the message-driven state. Referring to FIG. 4, a state diagram in an embodiment of the present invention, where a service call element (ServiceCall) 41 may represent a call to another remote service, such as specifying a called object and a called method body, setting a call parameter, etc., and The return value has been received before proceeding with the migration, and the next state can directly use the return value, so from the experience, it is exactly the same as the synchronous call. The service call primitive has three types of exits: call normal exit, call exception exit, and call timeout exit, which correspond to the three results of the service call: next state 42, exception handling 43, and timeout processing 44.

If the remote method body foo is called in the state diagram by synchronous call, the processing procedure is as follows: After the foo request is sent asynchronously in the method body F1, the method body Fl is halfway out, and the call stack information is The current running state is saved, and then the current thread is released. At this time, the thread can continue to process other calls. After the response message of the foo request arrives, the scheduling thread reschedules into the method body F1, and the call stack saved at the last exit is restored. Information and where you left off before exiting The pre-run state, and then continue to execute the subsequent logic from the pre-exit state until the logic of the method body F1 ends and exits the method body F1.

What is exemplified here is only an implementation solution. It can be understood that, in order to achieve the purpose of saving and recovering call stack information, it is not limited to such a scheme.

It can be seen from the technical solution that the call request message is sent by using an asynchronous call mode inside the method body, and during the waiting for the response, the thread is released, and other call requests can be processed, thereby ensuring the processing performance of the system; meanwhile, when receiving After the response message of the call request message is received, the saved call stack information may be directly restored to the running state before exiting the method body, and the subsequent logic is continued to be executed. Therefore, the subsequent logic may directly apply the call result of the current method body. For the developer, what is seen is only the processing of the method body and the sequential execution of the subsequent logic. The execution logic is not disturbed. Therefore, the complexity of business development can be reduced, and the efficiency of business development can be improved. In summary, the embodiments of the present invention can balance system processing performance and service development efficiency.

The method for the distributed call message in the embodiment of the present invention is described in detail below through a specific application scenario:

The specific scenario is as follows: The class CDemoClass calls the remote IF2 interface, and implements the distributed call in the method body StateProcess in the class CDemoClass. The following steps are described in detail with specific steps: Step 51: After the CDemoClass starts, enter the method body StateProcess A Context member of its own m-StateContext is passed as a node of the Context class linked list;

Step 52: The method body StateProcess creates a CStateProcessContext instance inside the method body and saves it in the Context class linked list;

Step 53: The method body StateProcess starts to migrate from the initial state;

Step 54: When the method body StateProcess is migrated to the method body call state, the IF2::foo(int a) interface method body needs to be called at the remote end;

1) First generate an object of the local proxy IF2 stub type, and then call the foo method body of the IF2 stub;

2) Inside the method body of IF2, a Context class instance is created and saved in the Context class list, and then enters the state machine of the foo method body. The state machine has two states: the send request status and the receive response status;

3) First enter the send request state, construct a call request message according to the asynchronous call mode and After being sent out through the soft bus, after sending, the current running state is set to the receiving response state, and the response message needs to be waited, and then the method body StateProcess is released, and the scheduling thread is released. At this time, all the call stack information is saved in the Context class.

Call information such as the called object, method body, and call parameters can be constructed as a call request message and sent.

Step 55: When receiving the response message returned on the soft bus, re-enter the method body StateProcess again, and find the current Context object from the Context chain according to the ID of the response message and resume the last call stack information, and continue execution from the exit point. , the method body that enters the IF2 stub again, directly migrates to the receiving request state, and returns the return value in the response message to return;

Step 56: Continue to execute subsequent processing logic, and the subsequent processing logic may directly use the return value of the method body StateProcess call.

It can be seen that, in this embodiment, since the call request message is sent in the asynchronous manner in the method body StateProcess, after the sending, the current running state is set to the receiving response state, and the response message needs to be waited, and then the method body StateProcess is released, and the scheduling thread is released. At this point all call stack information is stored in the Context class. When receiving the response message, it is again loaded into the method body StateProcess, and the current Context object is found from the Context chain according to the ID of the response message and the last call stack information is restored, and execution continues from the exit point, and the method body of the IF2 stub is again entered. Directly migrating to the receive request state, returning the return value in the response message, and continuing to execute the post-processing logic, which can directly use the return value invoked by the method body StateProcess. Therefore, during the waiting for the response, the thread can process other services, does not occupy the thread, and can ensure the processing performance of the system compared with the synchronous call; and for the developer, after receiving the response message of the call request message According to the saved call stack information, it can directly restore to the running state before exiting the method body, and continue to execute the subsequent logic. Therefore, the subsequent logic can directly apply the calling result of the current method body, and the developer sees Only the processing of the method body and the sequential execution of the subsequent logic, the execution logic is not disturbed, therefore, the complexity of business development can be reduced, and the efficiency of business development can be improved. In summary, the method for invoking messages used in this embodiment can simultaneously consider the processing performance and service development efficiency of the system.

The difference from the previous embodiment is that the technical solution adopts different call stack information saving and restoring methods, and the method is specifically: Firstly, an auxiliary class for saving a context relationship is defined: The following (Context) class, in fact, can generate a corresponding Context class for each method body, the method body parameters and local variables as members of the Context class, in the corresponding method body, access to parameters and local variables Convert to a member of the Context class. Moreover, when entering the method body, the Context object of the method body is linked to the Context class object of the upper method body, thereby forming a Context chain, so that the entire Context can be conveniently found even after the middle exit. chain.

When a distributed remote call is made, the call information is constructed as a request message and sent over the soft bus, the message is identified by a unique message ID, which is stored in the called Context; and the ID of the reply message It is consistent with the ID of the previously sent call request message. Therefore, when the response message returns, the corresponding Context object can be found according to the ID of the response message, and the saved call stack information is restored therefrom.

It will be understood by those skilled in the art that all or part of the steps of implementing the foregoing embodiments may be performed by a program to instruct related hardware, and the program may be stored in a computer readable storage medium. , including the following steps:

Sending a call request message asynchronously within the method body;

Saving the call stack information of the call request message and the current running state and exiting the method body; when receiving the response message of the call request message, restoring the saved call stack information; according to the restored call stack information, Resume to the running state before exiting the method body, and continue to execute the subsequent logic.

The above-mentioned storage medium may be a read only memory, a magnetic disk or an optical disk or the like.

The method and apparatus for distributed call message provided by the present invention are described in detail above. For those skilled in the art, according to the idea of the embodiment of the present invention, the specific implementation manner and the application range may be changed. In the above, the contents of this specification are not to be construed as limiting the invention.

Claims

Rights request

A method for distributedly invoking a message, comprising:

Sending a call request message asynchronously within the method body;

The method for the distributed call message according to claim 1, wherein the information of the call stack for saving the call request message is specifically: saving an identifier of the call request message and corresponding call stack information;

Recovering the saved call stack information is: searching and recovering the call stack information with the same identifier according to the received identifier of the response message corresponding to the call request message, where the identifier of the response message is preset The identifier of the call request message is the same.

The method for the distributed call message according to claim 1, wherein the method for saving the call stack information of the call request message is:

The identifier of the call request message and the call stack information are saved in a preset context class, where the class object corresponds to the method body, and the class object corresponding to the method body is linked to the upper method body. Forming a context class linked list on the class object;

The call stack information that is saved and saved is specifically: searching for a class object that is consistent with the identifier of the response message, and then restoring the saved call stack information corresponding to the type of the object, where the identifier and the call of the response message are preset. The identifier of the request message is the same.

The method for the distributed call message according to any one of claims 1 to 3, wherein the saved call stack information comprises: a called object, a method body, and a calling parameter.

The method for distributing a message according to any one of claims 1 to 3, wherein the executing the subsequent logic is specifically: executing one of the subsequent normal logic, executing the timeout processing logic, or executing the exception processing logic. .

A distributed processing device, comprising: a message invoking unit and an information processing unit, wherein:

The message invoking unit includes: a message sending unit, a message receiving unit, an information storage unit, Stack information maintenance unit, where: