CN112433716B

CN112433716B - Runtime component dynamic interaction model construction method based on non-invasive monitoring

Info

Publication number: CN112433716B
Application number: CN202011264976.1A
Authority: CN
Inventors: 李秋英; 陆民燕; 古廷阳
Original assignee: Beihang University
Current assignee: Beihang University
Priority date: 2020-11-12
Filing date: 2020-11-12
Publication date: 2022-04-01
Anticipated expiration: 2040-11-12
Also published as: CN112433716A

Abstract

A runtime component dynamic interaction model construction method based on non-intrusive monitoring comprises the steps of obtaining a runtime architecture model of a current adaptation stage; determining a monitoring object according to the runtime architecture model; declaring a proxy Bean in a monitoring method; declaring a monitoring Bean in the monitoring method to realize the extraction of dynamic calling information of the components; declaring interfaces of the agent Bean and the monitoring Bean; and constructing the model in operation based on a model construction algorithm, and the like, and constructing the model by extracting dynamic interaction information of the components.

Description

Runtime component dynamic interaction model construction method based on non-invasive monitoring

Technical Field

The invention relates to the field of control, relates to the field of model construction, and particularly relates to a runtime component dynamic interaction model construction method based on non-invasive monitoring.

Background

Adaptive tuning is a way to respond to changes in the operating environment by adjusting its structure and behavior. In the field of software engineering, the most common method for implementing software adaptation is software adaptation centered on architecture. The runtime model provides a concrete way and means for realizing the method, namely, the change of the model layer is mapped to the software layer by modifying the runtime model and utilizing the causal connection existing between the runtime model and the adaptive software, and finally the whole adaptive process is completed.

In order to ensure that the adaptive adjustment still provides high-quality service after the adaptation, an effective method is to analyze the influence of the adaptation change on the overall reliability level of the adaptive adjustment method at the model layer. However, the existing runtime model focuses on describing the composition and configuration of the system, lacks description of dynamic interaction information between components, and cannot predict the overall reliability level after adaptive adjustment and adaptation by directly using the model. Therefore, there is a need for a runtime model that can describe the dynamic interaction information between components, and by using the model, the prediction of the overall reliability level after adaptation in the model layer can be realized.

Disclosure of Invention

The invention aims to overcome the defects of the prior art, and provides a runtime component dynamic interaction model construction method based on non-invasive monitoring in order to obtain the runtime model capable of describing dynamic interaction information among components.

The invention provides a method for constructing a runtime component dynamic interaction model based on non-invasive monitoring, which comprises the following steps in sequence:

the method comprises the following steps: directly obtaining a runtime architecture model of the current adaptation stage through a Rainbow framework;

step two: determining a monitoring object according to the runtime architecture model;

step three: declaring a proxy Bean in a monitoring method;

step four: declaring a monitoring Bean in the monitoring method to realize the extraction of dynamic calling information of the components;

step five: based on the agent Bean and the monitoring Bean established in the third step and the fourth step, the interfaces of the agent Bean and the monitoring Bean are declared;

step six: and constructing the runtime model based on a model construction algorithm.

Further, the agent Bean in step three corresponds to the application Bean and has the same remote interface.

Further, the dynamic calling information of the components in the fourth step includes calling relation information, calling times information among the components, and timestamp information.

Further, the step of obtaining the call relation information includes:

the specific format of the call relation is defined as follows: ECS ═ caller, & >, where caller represents the EJB component that initiated the call, caller represents the called component, & represents the call relationship, and & is described as caller → caller;

the ECS is obtained through real-time monitoring, when the calling of the components is monitored, a row is added in the calling sequence among the components, the format of the calling pair is recorded as a called component of the calling component, and the obtained sequence is stored.

Further, the step of obtaining the information of the number of times of calls between the components includes:

and defining a list of the times of call between the storage components (ECT), wherein the format of the list is ECT ═ CALLER, CALLE, times >, and the times of call of the EJB component are obtained by scanning the sequence file obtained in the step of calling the relationship information.

Further, the scanning acquisition mode comprises:

counting calling pairs with the values of the first column of callers and the second column of callees in all the component calling frequency lists as A in the same mode, so that the total times of calling other EJB components and being called by other EJB components in the adaptation stage of the EJB component A can be respectively obtained; counting all call pairs with a caller of A and a caller of B, the total number of times that the component A obtains the component B can be obtained.

Further, the time stamp information obtaining step includes: and judging whether concurrence exists in the component calling process by recording the time of calling each component and the time of finishing calling.

Furthermore, in the component calling process, the definition component calling time stamp is a binary group<T_start,T_end>Wherein, T_startIndicating the moment of initiating the call, T_endIndicating the end time of the call;

when component A calls component B, simply A → B, then T_startIs represented by T (A)→B)_star，T_endDenoted T (A → B, B! A)_endB! A represents that the interface of the component A is unbound from the interface of the component B, namely the component B is executed completely.

Further, the specific steps for judging whether concurrence exists in the component calling process are as follows:

when the component A calls the component B, the time T of the call is recorded_startWhen the execution of the component B is finished, namely the interface of the component B is unbound with the interface of the component A, recording the calling end time T_end；

Recording the start time and end time of the call between the A component and the C component in the same way, if the A component calls the C component at the same time as the B component, the formula is satisfied in time T (A → B, B! A)_end＞T(A→C)_starIt is believed that there is a concurrency relationship between B, C components, where ">" indicates later.

Further, the model construction algorithm specifically includes the following steps: constructing an adjacency matrix of component calls by monitoring the collected component call sequences and the raw component call timestamp list at runtime, specifically comprising

(1) An input step:

1.1) a component calling sequence, wherein the calling among the components is recorded from a first line to a last line in the sequence;

1.2) an original component calling time stamp list, wherein, the list records the called time of the component from the first row to the last row IN sequence, each row comprises 3 columns, the first column is a component name, the second column is an identifier, values are IN and OUT, respectively represent that the component is called, the component is called after finishing, and the third column is the time when the component starts or finishes calling;

(2) an output step:

and the component calling model in the form of an adjacent matrix, wherein the value of the ith row and the jth column in the matrix represents the number of times that the component i calls the component j during running, and when the value is negative, the component i calls the component j while other concurrent calls exist.

The runtime component dynamic interaction model construction method based on non-invasive monitoring can realize that:

in the field of non-invasive monitoring research, most of research focuses on monitoring code layers, namely, monitoring call relations among functions, but the research on component-level monitoring is less, and currently, only a few frameworks for monitoring Java components are available, but the frameworks lack a specific and effective monitoring method. According to the method, whether the concurrent relation exists in the calling process of the components is judged by recording the timestamps called among the components.

Drawings

FIG. 1 is a diagram illustrating the detailed process of a client accessing an EJB;

FIG. 2 is a sequence diagram of a proxy Bean and a monitoring Bean obtaining component runtime information;

Detailed Description

Reference will now be made in detail to the embodiments of the present invention, the following examples of which are intended to be illustrative only and are not to be construed as limiting the scope of the invention.

For the applicable objects and the specific entering conditions, the monitoring objects applicable to the method are developed and constructed based on the Java platform because the construction of the runtime model is based on the Java reflection mechanism. Rainbow is a Java extension framework designed and realized by the institute of software engineering of Chimmonlon in a card, and a runtime architecture model with causal connection with adaptive software can be directly obtained through the framework.

Because the runtime architecture model obtained through the Rainbow framework in the current adaptation stage focuses on describing the composition structure of the system at the current moment, the dynamic relationship among the components is not described, and thus the runtime architecture model cannot directly support runtime reliability prediction. Therefore, on the basis of the current adaptation stage Runtime architecture Model, a Runtime Model capable of describing the static structure and dynamic behavior of the current adaptation stage Component is constructed, that is, a Runtime Component call Model (RCIM) Model of the current adaptation stage, where the Model includes the following dynamic information, call relationship between components, call times, and call timestamp.

Based on this, the invention provides a runtime component dynamic interaction model construction method based on non-invasive monitoring, which is specifically introduced as follows, and comprises the following steps:

the method comprises the following steps: directly obtaining a runtime architecture model of the current adaptation stage through a Rainbow framework, wherein the runtime architecture model can be directly obtained;

step two: the monitoring object is determined according to a runtime architecture model, wherein each component in the runtime architecture maintained by the model manager in the Rainbow framework has a system element corresponding to the component, which also means that the name and file address of each component in the runtime architecture model generated by Rainbow are the same as those of the elements in the system (controlled object). Since Rainbow is an extension framework based on J2EE (Java 2 Platform Enterprise Edition), each runtime architecture component can be considered to have an EJB (Enterprise Java Bean) component corresponding to it. Therefore, the monitoring object of the method is an EJB component corresponding to the component in the runtime architecture model.

Generating a proxy Bean and a monitoring Bean in an EJB container by using a Java reflection mechanism; then, collecting the calling information such as method calling, message forwarding, transaction processing and the like between the application program Bean corresponding to the agent Bean and the client through the monitoring Bean, and finally, recording and storing the monitoring information by using a file in an XML format. The monitoring method mainly comprises the following three steps of firstly, declaring an agent Bean; second, declare a monitoring Bean; third, the interface description of the client and the application Bean is given based on XML.

Step three: a proxy Bean in the monitoring method is declared.

The agent Bean corresponds to the application Bean one by one, has the same remote interface with the application Bean, receives the call of the client by using the same identification, and forwards the call information to the monitoring Bean. The generation of the agent Bean can declare a Bean having the same method as the application Bean by using a reflection mechanism provided by Java itself, and the specific declaration can be carried out in an XML or JAVAConfig based mode.

Where an EJB is a Java object that exists in a logical application service environment that provides the EJB components with the required service resources, such as the transactional context of a database, messaging, etc. Thanks to these services, EJB components can be declared by descriptors of XML files and used at deployment time to generate Wrapper classes (Wrapper classes) of EJB objects, which the client will replace the actual component objects with. The specific process of accessing an EJB by a client is shown in fig. 1, in which an EJB container is composed of an EJB Home object, an EJB object, and a real Bean.

When a client accesses an EJB, the client will request that the EJB Home object create an EJB object so that the client can access the public method (public method) provided by the real Bean to the client.

The EJB Home object, which is created after the request is received, is not a real Bean, but rather a server generated object that acts as a proxy between the client and the real Bean. This proxy, the EJB object, may provide other services to the EJB component, such as transactions, and the EJB object owns all the public methods of the real Bean and delegates the client's request to the real Bean.

When the client receives a reference to a newly created EJB object, the client can use all the public methods of the real Bean. Since the client does not directly access the real Bean, the client is actually calling the methods it needs on the EJB objects generated by the EJB container.

The EJB object forwards all method calls to the real Bean, which returns the operations and results needed for execution to the EJB object, which then returns the results to the client. Because EJB objects provide a large number of services for real beans, EJB objects can provide additional services for real beans in addition to the function of forwarding method calls. For example, an EJB object may verify that a client has the right to invoke a particular method, and may generate a transaction and invoke the required method in the context of the transaction. It should be noted that all of these additional services are transparent to the client, and do not require the developer to write any code in addition.

Step four: and declaring a monitoring Bean in the monitoring method to realize the extraction of the dynamic calling information of the component. The monitoring Bean mainly comprises the following two aspects, namely firstly, acquiring information in the agent Bean by a get method; and secondly, processing the acquired information according to the monitoring requirement. Since there may be a concurrent and selective (or sequential) relationship between the calls of the components, and this relationship will affect the result of reliability prediction, it is necessary to make explicit in the monitoring process whether there is a concurrent relationship between the components in the calling process.

The information to be extracted includes: the calling relationship among the components, the calling times among the components and the time stamp of calling among the components.

(1) Method for acquiring component calling relation

The specific format of the call relation definition among the components is as follows: ECS ═ caller, & >, where caller represents the EJB component that originated the call, caller represents the called component, and & represents the call relationship, and can be described specifically as caller → caller. The specific implementation of the ECS can be obtained through real-time monitoring, when the calling of the components is monitored, a row is added in the calling sequence among the components, the calling pair is recorded, the format of each row is 'calling component called component', and the obtained sequence can be saved in an ECS.

(2) Method for acquiring calling times of components

ECT (ejb Calling times) is a list of the number of calls between storage components, and its format is ECT ═ caller, call, times >. The number of calling times of the EJB component can be obtained by scanning an ECS (electronic component library). And counting the calling pairs with the value of the first column of callers in all the component calling frequency lists as A, so as to calculate the total frequency of the EJB component A calling other EJB components in the adaptation stage. Similarly, counting all the calling pairs with the value of the second column callee as A can calculate the total times of the EJB component A being called by other EJB components in the adaptation stage. And counting all calling pairs with the caller being A and the callee being B to obtain the total times of obtaining the component B by the component A.

(3) Time stamp obtaining method for calling between components

The judgment on whether concurrency exists in the component calling process can be realized by recording the calling time stamp of each component, namely the called time and the calling end time.

The component invocation timestamp is a doublet<T_start,T_end>Wherein, T_startIndicating the moment of initiating the call, T_endIndicating the end time of the call.

When component A calls component B, simply A → B, then T_startCan be represented as T (A → B)_star，T_endCan be represented as T (A → B, B! A)_end，T(A→B,B！A)_endB in (c! A represents that the interface of the component A is unbound from the interface of the component B, namely the component B is executed completely.

The following method can be adopted to judge whether concurrence exists in the component calling process. When the component A calls the component B, the time T of the call is recorded_startWhen the execution of the component B is finished, namely the interface of the component B is unbound with the interface of the component A, recording the calling end time T_end. Similarly, the call start time and the call end time between the a component and the C component can be recorded in the same way. If the A component calls the B component and the C component at the same time, satisfying in time (1) the expression where ">" indicates later, then a concurrency relationship between the components can be considered B, C.

T(A→B,B！A)_end＞T(A→C)_star (1)

In order to facilitate real-time data recording, the method records the timestamp called by the component by adopting the following original data format: each row of the original data represents the beginning or end of a component call, each row contains three columns, the first column is the component name, the second column is the component entry or exit identifier (i.e., the identifier that the component is called by beginning or end), and the third column represents the timestamp of the beginning or end call. By analyzing the original file, whether the call between the components is concurrent can be judged.

Step five: the interfaces of the proxy Bean and the monitoring Bean are declared based on XML.

The EJB component performs operations such as method calling, message forwarding, transaction processing and the like in an interface mode in the interaction process, so that the interface between the agent Bean and the monitoring Bean needs to be declared to realize that the monitoring Bean acquires the calling information of the agent Bean and specifies a corresponding data format. The call between EJB components has two forms of initiating call and called call, so the interface description is divided into XML description of component initiating call and XML description of component called.

The keywords and descriptions of the XML file are shown in the following table:

key word	Description of the invention
		InvokeInformation	Calling information
Component Name	Calling-initiated component name
		ClassName	Name of class or name of interface
MethodName	Name of method
		ReturnType	Type of return
ParameterType	Type of parameter
		EventName	Event name

The act of a component initiating a call can be viewed as the process of the component initiating a request externally. When the component initiates a calling request, the name of the component to be called and a series of information such as a required class, a required method, a required return value, a required parameter, an event and the like need to be declared, and then the called component meeting the requirements is searched through the relevant rules of the management module in the EJB container, and the called component interacts with the called component to finally complete the calling process.

When a component is called, it can be viewed as a process by which the component provides services to the outside. When called, a component needs to provide its own method, function, return type, parameter type, and other information. When the component is required to be called by the function or the business process, the component can interact with other components through the information, so that the calling is completed.

Step six: the design algorithm realizes the construction of a runtime model:

specifically, an adjacency matrix called by the components is constructed by monitoring the collected component calling sequence and an original component calling time stamp list in the runtime;

(1) the input of the algorithm is as follows:

1) the method comprises the following steps that a component calling sequence is adopted, and the calling among the components is recorded from a first line to a last line in the sequence in sequence;

2) the original component calls a time stamp list, and the list records the called time of the component IN sequence from the first row to the last row, wherein each row comprises 3 columns, the first column is the component name, the second column is the identifier, the values are IN and OUT, which respectively represent that the component is called, the component is called at the end, and the third column is the time when the component starts or finishes calling.

(2) Output of the algorithm

(3) Basic steps of the algorithm

1) Initializing an empty call stack and a temporary stack tmpStack;

2) saving the first component name in the original component calling time stamp list in a variable preComp;

3) for each row in the list of timestamps:

storing the first row and the first column into a variable compName

Storing the second row and the second column into a variable probability

③ if the node is IN:

firstly, pressing the comp name into a stack;

subsequently, a judgment is made:

if the adjacent matrix has a certain row name which is the same as the comp name, adding 1 to the values of the preComp row and the comp name column;

otherwise, adding a row and a column in the adjacency matrix, wherein the name of the row and the column is comp name, and initializing the values of the preComp row and the comp name column to be 0;

if the mutation is OUT:

firstly, reading the top element of the stack, and judging:

if the stack top element name is comp name:

firstly, popping the stack top element from a stack;

then, if the elements exist in the tmpStack, popping and pushing the elements in the stack in sequence;

otherwise, it means that other components have been concurrently called before the compName component is called, and at this time:

firstly, setting elements of preComp rows and a stack top element name column of an adjacent matrix and elements of preComp rows and a comp name column as negative numbers;

then, popping up stack top elements of the stack, and pressing the stack top elements into the tmpStack;

subsequently, continuously reading stack top elements of the stack, and continuously judging;

the first element left at the top of the stack is then stored in the variable preComp.

Although exemplary embodiments of the present invention have been described for illustrative purposes, those skilled in the art will appreciate that various modifications, additions, substitutions and the like can be made in form and detail without departing from the scope and spirit of the invention as disclosed in the accompanying claims, all of which are intended to fall within the scope of the claims appended hereto, and that the various parts of the product and steps of the method claimed herein can be combined in any combination. Therefore, the description of the embodiments disclosed in the present invention is not intended to limit the scope of the present invention, but to describe the present invention. Accordingly, the scope of the present invention is not limited by the above embodiments, but is defined by the claims or their equivalents.

Claims

1. A runtime component dynamic interaction model construction method based on non-intrusive monitoring is characterized by comprising the following steps which are carried out in sequence:

step three: declaring a proxy Bean in a monitoring method;

step six: the method comprises the following steps of realizing the construction of a runtime model based on a model construction algorithm, wherein the model construction algorithm specifically comprises the following steps: constructing an adjacency matrix of component calls by monitoring the collected component call sequences and the raw component call timestamp list at runtime, specifically comprising

(1) An input step:

(2) an output step:

2. The method of claim 1, wherein: and the agent Bean in the third step corresponds to the application Bean and has the same remote interface.

3. The method of claim 1, wherein: and in the fourth step, the dynamic calling information of the components comprises calling relation information, calling frequency information among the components and timestamp information.

4. The method of claim 3, wherein: the step of acquiring the calling relation information comprises the following steps:

5. The method of claim 3, wherein: the step of obtaining the calling frequency information among the components comprises the following steps:

6. The method of claim 5, wherein: the scanning acquisition mode comprises the following steps:

7. The method of claim 3, wherein: the time stamp information acquiring step includes: and judging whether concurrence exists in the component calling process by recording the time of calling each component and the time of finishing calling.

8. The method of claim 7, wherein: group ofIn the process of calling the component, defining the time stamp of calling the component as a binary group<T_start,T_end>Wherein, T_startIndicating the moment of initiating the call, T_endIndicating the end time of the call;

when component A calls component B, simply A → B, then T_startDenoted T (A → B)_star，T_endDenoted T (A → B, B! A)_endB! A represents that the interface of the component A is unbound from the interface of the component B, namely the component B is executed completely.

9. The method of claim 7 or 8, wherein: the method for judging whether concurrency exists in the component calling process comprises the following specific steps: