JP2001282556A - Device and method for deciding dynamic data flow by action chain, computer readable recording medium and program deciding dynamic data flow by action chain - Google Patents

Abstract

PROBLEM TO BE SOLVED: To flexibly constitute and change an event processing while the versatility and independence of an action are secured on a dynamic data flow deciding device by an action chain in an event processing in a distributed system. SOLUTION: A part which is executed at the time of an event processing is separated as the action and event processing definition can be constituted and changed from action parts. When a received message is an event object, an action execution part 14 ignites a flow control part 20. The flow control part 20 repeats the selection/execution of the action parts existing in an agent in accordance with the type and the state of an event. Thus, the action chain is generated and a dynamic data flow is decided.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to event processing in a distributed system in which a plurality of computers connected by a network cooperate, and in particular, to a dynamic data flow determining apparatus using an action chain that enables a flexible chain of actions. About. Applicable technology is CORBA
, DCOM, Java RMI and other distributed object-oriented platforms.

[0002]

2. Description of the Related Art In the development of a distributed processing system, an event processing model plays an important role. By designing an interface of objects that cooperate with each other using an event processing model based on appropriate rules, it is possible to understand local behavior even in a large-scale and complicated distributed system. . This makes it possible to easily add new objects to the system, expand functions, and cut off unnecessary parts.

A general event processing model in a conventional distributed system will be described. An object that delivers an event is called an event source, and an object that receives an event and performs some processing is called an event listener.

FIG. 15 shows an example of a class definition based on a conventional event processing model, and FIG. 16 shows an example of the event processing sequence. The event source object (Source object) is an interface for registering at least an event listener from outside (here,
The object that has addEventListener () and acts as an event listener (Listener object) is an action method (here,
action ()).

When the reference pointer of the event listener is addEvent
Event source (Source object) by Listener ()
When the event source is registered, the event source calls a predetermined action method using a reference pointer of the registered event listener when some state change occurs (status changed). As a result, processing linked to the occurrence of an event can be performed on the distributed system.

The problem with this model is that the behavior of the event listener cannot be changed during execution because the processing executed when an event occurs is defined as a method of the event listener. Another problem is that whether each object acts as an event source or an event listener is determined at the time of designing each object.
At runtime, the role cannot be changed.

[0007]

An agent action model (action-separated event processing model) has been devised to solve the problems of the conventional event processing model. FIG. 17 shows an example of a class definition based on the action separation type event processing model, and FIG. 18 shows an example of the event processing sequence.

In this model, an event listener is separated from an action, which is a definition of an action, at an object level so that the behavior when an event occurs can be changed at the time of execution. Event sources and event listeners are source agents (Sour
ce agent and Listener age
(nt).

In the above-described event processing model, event processing is performed by calling a method of a predetermined event listener. However, in the agent action model, a specific method is used instead of calling a specific method. , And sends only the event as a message to the agent that becomes the event listener (listener agent). Since the listener agent selects and executes an action that matches the received message, it is possible to change the behavior at the time of event reception by replacing actions with the same input pattern and different implementations. In addition, since the object that becomes the event source and the object that becomes the event listener are derived from the same agent, there is no distinction at the object level, and the role can be dynamically determined by a combination of actions.

However, the agent action model also has disadvantages. That is, it is difficult to express a process executed by occurrence of an event by a chain of a plurality of actions as shown in FIG. As shown in FIG. 20, for example, a data flow based on such a chain of actions is described such that the next action “A # 4” is called inside the action “A # 1” (call (“A # 4
4 ");) to achieve this, but
Since a code valid only in a specific situation is embedded in the action, the versatility and independence of each action are lost, which is not preferable.

An action is called by RPC (R
emote Procedure Call) and method calls are synchronous, so when n action chains are executed, n threads will be created, and the longer the action chain, the more memory and memory CPU
Another problem is that the load imposed on the device increases.

[0012]

In order to solve the above problems, the present invention realizes a process executed in synchronization with the occurrence of an event by a data flow model using a chain of actions in an agent action model. However, in the configuration of the conventional agent, a flow control means for selecting an action to be fired according to the type of the received event object and managing execution of the data flow is provided.

The flow control means generates an action chain by repeatedly selecting and executing an action existing in the action / attribute storage area in accordance with the type and state of the event, and determines a dynamic data flow.

This flow control means can be implemented as one of special actions in the action / attribute storage area.

The present invention operates as follows. If the message from another agent is an action execution request, the message is transferred to the action execution means. In the action execution means, the action with the name specified in the parameter of the execution request of the received message
It checks whether it exists in the action / attribute storage area, and if there is an action with the same name, executes that action and waits for the processing to be completed. When the execution of the action is completed, the execution result is returned to the requesting agent.

The action executing means activates the flow control means when the parameter of the execution request is an event object.

The flow control means creates a message pattern based on the event object which is a parameter of the execution request, transmits an action execution request in which the destination address is set to itself to the message transmission means, and waits for the execution result. . The execution result is returned via the action execution means. Thereafter, the same processing is repeated.

That is, a message pattern is created based on the event object, and an action execution request is issued. If the returned execution result is a list of action names, duplicate the event object to execute the listed actions in parallel,
The execution request of the flow control means is performed recursively using each action name as a parameter. If no data is included in the returned execution result, the process is terminated and the chained execution of the action is stopped.

As described above, in the present invention, the independence of the actions constituting the data flow is ensured, and the event processing procedure is easily defined and constructed once by combining the general-purpose action components. Event processing procedures can be customized easily.

The action chain is determined to some extent by checking the consistency between the input pattern indicating the type of event object that can be handled by the action and the type of the event object that has actually occurred. Since an appropriate flow can be determined, the burden on the designer of the data flow can be reduced, and there is an effect of avoiding defining an erroneous flow. Separating the definition of an action from the definition of its input pattern so that a widely applicable action implementation can be applied to a flow for a particular event type, the event type of the action's input pattern You only need to set to a narrow type, and you do not need to change the implementation of that action.

In addition to the definition of the input pattern, not only the type of the event, but also the attribute value of the received event object, the name and type of the action executed immediately before, etc. can be defined as required. This makes it possible to control the order of actions in the data flow.

[0022]

Embodiments of the present invention will be described below.

FIG. 1 is a diagram showing an example of the system configuration of the present invention. The dynamic data flow determining device (agent) 1 according to the present invention includes a message receiving unit 11, an action managing unit 12, a pattern matching processing unit 13, an action executing unit 14, an action / attribute storing unit 15, and a message transmitting unit 16. , The action / attribute storage unit 15 is provided with a flow control unit 20 which is a feature of the present invention, in addition to each action (actions # 1 to #n).

The message receiving unit 11 has a queue for temporarily storing messages transmitted from other agents, and distributes the messages to individual processing units (modules) inside the agent according to the types of messages. The action management unit 12 receives a request to change the configuration of the action of the agent from the outside, and changes the action configuration based on the request. The pattern matching processing unit 13
Compares the parameter list of the message received as the action execution request with the input pattern of the action stored in the agent, and selects the matching action. The action execution unit 14 manages execution of the action stored in the action / attribute storage unit 15. The action / attribute storage unit 15 is an area for storing each action and the code of the flow control unit (action) 20. The message transmitting unit 16 receives a message related to action management, an execution request, and the like, and transmits the requested message to the corresponding agent.

The flow control unit 20 is realized, for example, as one of actions, and receives an event object which is a parameter of an execution request from the action execution unit 14, and
A process of creating an action execution request that sets itself as the destination address, sending it to the message sending unit 16, waiting for the execution result, receiving a new event object that is the execution result, and creating and sending the execution request again Is repeated to control the flow. That is, the flow control unit 20 is activated when the received message is an event object, and repeats the selection and execution of the action component existing in the agent according to the type and state of the event, thereby forming an action chain. It has the ability to create and determine dynamic data flows.

As shown in FIG. 2, a changeable input pattern 21 'may be provided in the action / attribute storage unit 15 in a storage area for each action (# 1 to #n) separately from the action. Good. This is effective in a case where even if the implementation of the action is a compiled program, the input pattern can be changed without replacing the action.

As shown in FIG. 3, an area for storing the pattern match rule 132 for each action may be provided in the action / attribute storage unit 15. In this case, the pattern matching processing unit 13 checks the adaptability of the input pattern with reference to the pattern matching rule 132 held by each action. By doing so, it is possible to extend the rules of pattern matching with the ease of replacing actions.

The processing flow of each means will be described below.
FIG. 4 shows a processing flow of the message receiving unit 11. The message receiving unit 11 determines the type of the message (step S1), and if the received message is an action addition / deletion / replacement request, transfers the message to the action management unit 12 (step S2).
If the received message is an action execution result, the message is transferred to the action execution unit 14 (Step S
3). If the received message is an action execution request, the message is sent to the pattern matching processing unit 1
3 (step S4).

FIG. 5 shows a processing flow of the action management unit 12. The action management unit 12 determines the processing type of the received message in the reception waiting state (step S21). When an action addition request (parameter: name, action) is received, the name ( It is checked whether an action having the same name as the (action name) exists in the action list storage area (step S22). If an action with the same name exists, an error message is transferred to the message transmitting unit 16 and sent to the requesting agent. It is returned (step S23). Otherwise, the action, which is a parameter of the addition request, is additionally stored in the action / attribute storage unit 15 with the designated name (step S24).

When the action management unit 12 receives the action replacement request (parameter: name, action), whether an action having the same name as the parameter (action name) of the replacement request exists in the action list storage area. Check whether (Step S2
5) If there is no action with the same name, an error message is returned to the requesting agent (step S23). Otherwise, the action with the same name is deleted from the action / attribute storage unit 15 (step S26),
The action, which is a parameter of the replacement request, is additionally stored in the action / attribute storage unit 15 as an action having the same name (step S27).

When the action management unit 12 receives the action deletion request (parameter: name), whether an action having the same name as the name (action name) which is a parameter of the deletion request exists in the action / attribute storage unit 15. It is checked whether or not there is an action with the same name (step S28), and an error message is returned to the requesting agent (step S23). Otherwise, the action having the same name is deleted from the action / attribute storage unit 15 (step S29).

FIG. 6 shows a processing flow of the pattern matching processing section 13. Upon receiving the action execution request (parameter), the pattern matching processing unit 13 empties the action list (step S30), and for all actions, matches the parameter list of the received message with the input pattern of each action. Is checked (step S31), and the name of the applicable action is added to the action list (step S32). After checking all the actions, if no action is selected, an error message is returned to the transmission source agent (step S33). If only one action has been selected, an execution request for that action is transmitted to the action execution unit 14 (step S).
34). When a plurality of actions are selected, the action list is returned to the source agent (step S35).

FIG. 7 shows a processing flow of the action execution unit 14. Upon receiving the execution request, the action execution unit 14 checks whether an action having the name specified in the parameter of the execution request exists in the action / attribute storage unit 15 (step S40). Is returned to the requesting agent (step S41). If an action with the same name exists, the action is executed (step S42), and the process is waited for to be completed (step S43). When the execution of the action is completed, the execution result is returned to the requesting agent (step S44). Action execution unit 1
4 receives the execution result of the action, notifies the execution result of the execution to the request source action waiting for the received execution result (step S45).

Here, when the parameter of the message of the execution request is an event object, the flow control unit 20 is activated as an action for firing, and dynamic flow control is performed.

FIG. 8 shows a processing flow of the flow control unit 20. The action execution unit 14 controls the flow control unit 20
Is activated, the flow control unit 20 creates a message pattern based on the event object which is a parameter of the execution request (step S50), and sends an action execution request in which the transmission destination address is set to itself to the message transmission unit. 16 (step S51), and waits for the execution processing result (step S52). The processing result is returned to the flow control unit 20 by the action execution unit 14,
The processing of the flow control function is continued again.

If there is a processing result (step S53), the flow control unit 20 checks the type of the processing result (step S54). If the processing result is an event object, the above-described steps S50 to S54 are performed. Is repeated. That is, a message pattern is created based on the event object, and an action execution request is issued. Here, in order to avoid firing of unnecessary actions, a memory for storing the executed action list may be provided in the event object, and the name of the action executed immediately before may be stored in the executed action list (step S55). .

If the returned execution result is a list of action names, an event object is duplicated to execute the listed actions in parallel (step S57), and each action name is set as a parameter. The execution request of the flow control unit 20 is made recursively (step S58).

Here, in order to avoid firing of unnecessary actions, a memory for storing the executed action list is provided in the event object, and the action name listed here is included in the selected action list. In step S56, the action names may be deleted from the action list so that the executed action is not executed once (step S56). If no data is included in the returned execution result, the flow control unit 20 ends and stops the chained execution of the action.

FIG. 9 shows a processing flow of the message transmitting section 16. When receiving any message (transmission request), the message transmitting unit 16 checks the destination address of the received message and checks whether it is addressed to itself (step S60). The received message is transferred to the message receiving unit 11 of the agent (step S61). If not, according to the destination address of the message,
Forward the message to another agent (step S
62).

The following is an example of a specific embodiment implemented using the Java language. The present invention is not limited to the Java language, and can be applied to a case where the present invention is implemented using another programming language.

[1] Embodiment of Flow Control Unit 20 (Flow Controller) The flow control unit 20 can be implemented as one of actions (FlowController) for defining the behavior of the agent. The flow control unit 20 (hereinafter, FlowCo)
The message pattern as a condition for firing ntroller) has one parameter and its type is an event object, and its definition is as follows.

[0042] When the agent receives the object of EventObject class, the start () method of FlowController is executed. For example, in the start () method of the present embodiment, the EventEvent of the argument is expanded into the following message pattern and transmitted to itself.

<Event object>, <event source>, <event attribute>, <previous action name>, <result of execution of previous action> Here, the event source first generates the received event object. The event attribute is an attribute value of the event object, and is allowed to be changed during the action chain.

Example 1 Example of Action Chain Assume that the following two actions are added to an agent.

[0045] Here, Event_A, Event_B, Event_C are all EventO
Suppose it is a subclass of bject. That is, it becomes as follows.

Public class Event_A extends EventObject ｛...｝ public class Event_B extends EventObject ｛...｝ public class Event_C extends EventObject ｛...｝ At this time, the action management unit 12 is added in accordance with the FlowController. Set the input pattern of each action as follows.

Input pattern of ActionOne: @Event_A.
class, AgentAddress.class, Object.class, String.cl
ass, Object.class｝ Input pattern of ActionTwo: ｛Event_B.class, Agent
Address.class, Object.class, String.class, Object.c
lass｝ where the notation Event_A.class refers to the class Event
Indicates that any object of _A is acceptable. Similarly, String.class indicates that any string is acceptable.
The input pattern of FlowController is as follows.

{EventObject.class} Here, consider the case where Event_A is transmitted to this agent. As explained below, the chain of actions results in the FIG.
0 (A). FlowController at this time
Fig. 10 shows the relationship between ActionOne and ActionTwo.
It is shown in (B).

The format of the message received first is of the form {event_A}, where event_A is of class Eve
Let it be an instance of nt_A. At this time, only the FlowController is selected and executed by the pattern matching processing unit 13 as a match among the above three input patterns. FlowController receives the event_
Generate the following message pattern from A and send an action execution request.

｛Event_A, event_A.source (), event
_A.attribute (), null, null {Here, the pattern matching processing unit 13 selects and executes only ActionOne as a match among the three input patterns. ActionOne takes Event_A as an argument, and Event_A
To return B as a return value, FlowController next generates the following message pattern and sends an action execution request.

｛Event_B, event_B.source (), event
_B.attribute (), "ActionOne", null {Here, only the ActionTwo is selected by the pattern matching processing unit 13 as a match among the three input patterns.
Be executed. ActionTwo takes Event_B as an argument and
FlowController returns vent_C as a return value.
Next, the following message pattern is generated and an action execution request is transmitted.

｛Event_C, event_C.source (), event
_C.attribute (), "ActionTwo", null {Here, the pattern matching processing unit 13 sends an error message to Flow
Return to Controller. Therefore, the chain of actions stops.

In this way, for the occurrence of Event_A, the data flow of ActionOne → ActionTwo can be defined simply by adding each action to the agent. This is one of the major features of the present invention.

When it is desired to add a new flow without affecting the existing data flow, it is often necessary to simply add an action. For example, consider a situation in which an ActionTree with the following Event_A input is further added to the agent.

[0055] Here, when Event_A occurs, the first action selected by the pattern matching processing unit 13 is Acti.
ActionOne → ActionT because onOne and ActionThree
The flow of wo and the flow of ActionTree are executed simultaneously.

The chain of actions results in FIG.
As shown in FIG. FlowController at this time
And the relationship among ActionOne, ActionTwo, and ActionTree are as shown in FIG.

Example 2 Restriction on Flow by Action Name In Example 1 described above, there was no problem because all actions forming the data flow had different event types as inputs. However, if ActionTwo is defined so as to expect the input of Event_A similarly to ActionOne, all actions are fired simultaneously, and the expected data flow is not determined. In this case, when adding each action, the input pattern may be customized, and the name of the action executed immediately before may be explicitly specified to restrict the flow. For example, assume that all three actions handle Event_A for both input and output.

Public class ActionOne extends Action ｛public Event_A start (Event_A event) ｛... ｛｝ public class ActionTwo extends Action ｛public Event_A start (Event_A event) ｛...｝｝ public class ActionThree extends Action ｛public Event_A start (Event_A event) ｛｝｝｝ Here, when each action is added, a change is made to specify a specific action name in the fourth item of the input pattern.

Input pattern of ActionOne: @Event_A.
class, AgentAddress.class, Object.class, String.cl
ass, Object.class 入 力 Input pattern of ActionTwo: ｛Event_A.class, Agent
Address.class, Object.class, "ActionOne", Object.c
lass｝ ActionThree input pattern: ｛Event_A.class, Age
ntAddress.class, Object.class, "ActionTwo", Objec
t.class｝ Assume that Event_A occurs in the agent in this state. The first item of the input pattern is Event_A.cl
Since it is ass, all can be candidates, but FlowControll
Since the fourth item of the message sent by er is null,
The only action finally selected is ActionOne. After the completion of ActionOne, the fourth item of the message sent next by FlowController is the name of the action executed immediately before, "ActionOne", so the only action selected is ActionTwo.

Thus, the data flow actually determined for Event_A is ActionOne → ActionTwo
→ ActionThree. The result of this chain of actions is shown in FIG. Also, FlowController at this time
FIG. 12B shows the relationship among the ActionTree, ActionOne, ActionTwo, and ActionTree.

<< Example 3 >> Expression of IF-THEN Rule by Input Pattern As an advantage of pattern matching, it is possible to not only express a flow only in series, but also apply a flow of a general conditional branch to each action without any modification. There is a merit that only the input pattern needs to be customized. For example, the same two actions, ActionOne and Action, as in Example 2
Assume that an action that returns an object of the following Boolean type is added to Two.

Public class ConditionalAction extends Action ｛public Boolean start (Event_A event) ｛if (...) return Boolean.TRUE; else return Boolean.FALSE;｝ 入 力 Each input pattern is as follows, and ActionOn
The condition of the fifth item in the input pattern of e and ActionTwo has been changed to TRUE and FALSE of the Boolean class, respectively.

Input pattern of ActionOne: @Event_A.
class, AgentAddress.class, Object.class, String.cl
ass, Boolean.TRUE｝ Input pattern of ActionTwo: ｛Event_A.class, Agent
Address.class, Object.class, String.class, Boolea
n.FALSE｝ Input pattern of ConditionalAction: ｛Event_A.clas
s, AgentAddress.class, Object.class, String.class,
Object.class で In this state, the first action fired by Event_A is ConditionalAction, which has no condition in the fifth item, but this action returns Boolean.TRUE
Returns Boolean.FALSE determines whether the next action performed will be ActionOne or ActionTwo. In other words, conditional branch-type flows such as IF-THEN rules can be realized by customizing input patterns.

FIG. 13 shows a chain of actions in this example.
(A) shows the FlowController and Conditio at this time.
The relationship with nalAction, ActionOne and ActionTwo is
It is shown in FIG.

[2] Application Example in Personal Agent As a specific application example of the present invention, an example of dynamic notification of a service event in a personal agent will be given. Users can use various network services (e-ma
In some cases, the user may want to be notified of an event such as an incoming call, incoming call, or schedule update at any time. Further, the user sometimes wants to frequently change communication terminals such as a personal computer (PC) and a mobile phone depending on a place or a situation. The role of the personal agent is to use the communication terminal currently in use by the user to inform the user of events of various services in an expression suitable for the terminal.

For example, when the user receives a schedule update event from the calendar service, the message "displays on the PC screen if the user's PC is connected to the network; otherwise, a short message on the mobile phone informs the user. Suppose you want to "notify". FIG. 14 shows an action configuration for event notification in the personal agent (PA) in this case.

The personal agent (PA) 51 has three actions (IsPcOnline, SendToPHS, SendToP
C) has been added. The action IsPcOnline is a module that returns TRUE if the PC being used by the user is connected to the network, and returns FALSE otherwise. In addition, action SendToPC and action Se
The ndToPHS is a module for transferring an event to TA (PC) 52 and TA (PHS) 53 which are software in which low-level control for a PC terminal and a PHS terminal is trapped by an agent, respectively. Also, the action Se
It is assumed that the input patterns of ndToPC and action SendToPHS are set as follows, respectively.

Input pattern of SendToPC: @EventObject.
class, AgentAddress.class, Object.class, String.cl
ass, Boolean.TRUE 入 力 Input pattern of SendToPHS: ｛EventObject.class, Age
ntAddress.class, Object.class, String.class, Boolea
n.FALSE｝ This example operates on the same rules as Example 3 above. if,
PA 51 is a calendar service (CalendarService) 54
Receives the schedule update event from the PC
Is online, IsPcOnline, SendTo within PA51
The actions are fired in the order of the PCs, and the schedule event is transferred to the agent TA (PC) 52 that controls the PC. In the agent TA (PC) 52, an action Defa that converts information of the event into dialog data
ultScheduleToDialog operates, and the action DisplayDialog that receives dialog data and displays it on the screen operates. Thereby, the user sitting in front of the PC can be notified of the schedule update.

If the user's PC is offline, the action IsPcOnline returns FALSE.
The event is transferred to the agent TA (PHS) 53 that controls the mobile phone via ndToPHS. In the agent TA (PHS) 53, the action DefaultSchedul that converts the information of the event into a short message
eToSMS operates, and the action SMSend that sends the converted short message data to the mobile phone network operates.
As a result, it is possible to notify the user who is away from home with the mobile phone of the schedule update.

The first parameter of the input pattern in the three actions of the PA 51 is EventObject.class
In this case, the same event notification rule is applied to all events, so that it can be applied not only to schedule update but also to any service event such as incoming e-mail or incoming call.

Conversely, when the above notification rule is to be applied to a specific service, a series of actions of an input pattern restricted to the type of an event transmitted by the service are added to the PA 51, so that the PA 51 is originally provided. It can be customized without affecting the defined action chain.

[0072]

As described above, the present invention has the following effects.

(1) In event processing in a distributed system, an action executed when an event object is received is separated from a server object, and a flow control means for selecting an action to be fired according to the type of the received event object is provided in the server object. With the provision, it is possible to dynamically introduce new event processing without affecting other actions in the server object.

(2) The definition of the action to be executed when the event object is received is separated from the definition of the input pattern as a condition for selecting the action, and the definition of the input pattern can be changed without changing the definition or configuration of the action. By changing, the behavior for the event can be changed.

(3) If the action executed when the event is received returns an event object as the execution result, the flow control means checks the type of the newly received event object, and selects the next action to be fired. By repeating the execution, a dynamic data flow can be determined.

(4) It is possible to control the firing of an action by allowing the definition of the input pattern to set not only the type of the event object but also the value of the event object or the value of the attribute of the event object. It becomes possible.

(5) The name of the action expected to be executed immediately before is allowed to be set in the definition of the input pattern, and the flow control means checks the definition at the time of selecting the action to execute the action. The order of actions to be performed.

(6) When the flow control means selects an action, a function of storing a list of already executed actions is provided, and a rule which is not set to be fired for an action once executed is provided. Infinite loop can be avoided.

As described above, in the event processing as a mechanism of cooperation between objects in a distributed system,
By defining the event processing definition part as an independent component called an action, it is possible to dynamically replace the behavior or add a new behavior without affecting the existing behavior. Furthermore, by adding a flow control function, it is possible to realize an event processing definition with a chain of multiple actions, thereby ensuring the independence of the action components that make up the event processing and reusing the action components. Has the effect of increasing

[Brief description of the drawings]

FIG. 1 is a diagram showing a system configuration example of the present invention.

FIG. 2 is a diagram illustrating a configuration example (part 1) of an action / attribute storage unit.

FIG. 3 is a diagram illustrating a configuration example (part 2) of an action / attribute storage unit.

FIG. 4 is a processing flowchart of a message receiving unit.

FIG. 5 is a processing flowchart of an action management unit.

FIG. 6 is a processing flowchart of a pattern matching processing unit.

FIG. 7 is a processing flowchart of an action execution unit.

FIG. 8 is a processing flowchart of a flow control unit.

FIG. 9 is a processing flowchart of a message transmission unit.

FIG. 10 is a diagram showing an example of an action chain.

FIG. 11 is a diagram illustrating an example of an action chain.

FIG. 12 is a diagram illustrating an example of an action chain.

FIG. 13 is a diagram illustrating an example of an action chain.

FIG. 14 is a diagram showing a configuration example of an action configuration for event notification in a personal agent.

FIG. 15 is a diagram showing an example of a class definition based on a conventional event processing model.

FIG. 16 is a diagram showing an example of a conventional event processing sequence.

FIG. 17 is a diagram illustrating an example of a class definition based on an action-separated event processing model.

FIG. 18 is a diagram illustrating an example of an action separation type event processing sequence.

FIG. 19 is a diagram illustrating an example of a data flow by an action chain.

FIG. 20 is a diagram showing an example of implementing an action chain according to the related art.

[Explanation of symbols]

 REFERENCE SIGNS LIST 1 dynamic data flow determination device (agent) 11 message receiving unit 12 action management unit 13 pattern matching processing unit 14 action execution unit 15 action / attribute storage unit 16 message transmission unit 20 flow control unit 21 input pattern

Claims (10)

[Claims] 1. An apparatus for dynamically determining a data flow by an action chain in event processing in a distributed system, wherein information relating to an action executed when an event object is received is stored separately from a server object. A storage unit, and a flow control unit that selects an action to be fired from the actions stored in the action / attribute storage unit according to the type of the received event object, and realizes an action chain by the flow control unit. A dynamic data flow determining device using an action chain. 2. The dynamic data flow determining apparatus according to claim 1, wherein said action
The attribute storage unit stores the definition of the action executed when the event object is received and the definition of the input pattern as a condition for selecting the action in a separated form,
A dynamic data flow determining device based on an action chain, wherein the behavior of an event is changed even if the definition or configuration of an action is not changed by changing the definition of an input pattern. 3. The dynamic data flow determining apparatus based on an action chain according to claim 1, wherein the flow control unit newly sets an event as an execution result when the action executed at the time of receiving the event returns an object. A dynamic data flow determining device based on an action chain, wherein a dynamic data flow is determined by repeatedly checking a type of a received event object, and repeatedly selecting and executing an action to be fired. 4. The dynamic data flow determining apparatus according to claim 2, wherein said action
In the definition of the input pattern stored in the attribute storage unit, not only the type of the event object but also the value of the event object or the value of the attribute of the event object can be set, and the action is fired by the definition of these input patterns. A dynamic data flow determination device based on an action chain, characterized in that the device is controlled. 5. The dynamic data flow determining apparatus according to claim 2, wherein said action
The name of the action expected to be executed immediately before can be set in the definition of the input pattern stored in the attribute storage unit, and the flow control means checks the definition of the input pattern when selecting an action. A dynamic data flow determining device based on an action chain, wherein the sequence of actions to be executed is controlled by performing the operations. 6. The dynamic data flow determining apparatus according to claim 3, wherein said flow control means stores a list of actions already executed when an action is selected, and the action executed once is a list of actions executed once. A dynamic data flow determining device based on an action chain, wherein an infinite loop of the data flow is avoided by removing the data flow from firing. 7. An apparatus for dynamically determining a data flow by an action chain in event processing in a distributed system, comprising: an action / attribute storage unit for storing definition information on an action; a message receiving unit for receiving a message; A message transmission unit for transmitting a message, an action management unit for changing definition information about the action when the received message is a request for changing the definition information about the action, and a message management unit for changing the definition information about the action. A pattern matching processing unit that selects a matching action by comparing the parameter list with information stored in the action / attribute storage unit, an action execution unit that manages execution of the selected action, The axi A dynamic data flow determination device based on an action chain, comprising: a flow control unit which is activated by an action execution unit and controls the selection and execution of an action to be fired next according to the type of the received event object. 8. A method for dynamically determining a data flow by an action chain in event processing in a distributed system, wherein an action executed when an event object is received is separated from a server object, and a server object is separated according to a type of the received event object. A flow control means for selecting an action to be fired is provided in the server object, and the flow control means selects and executes the next action to be fired without affecting other actions in the server object. A dynamic data flow determination method using an action chain, which dynamically introduces a new event process. 9. A recording medium recording a program for realizing, by a computer, a device for dynamically determining a data flow by an action chain in event processing in a distributed system, comprising: a message receiving process for receiving a message; Message transmission processing, when the received message is a request to change the definition information about the action, action management processing to change the definition information about the action, and the parameter list of the message received as the action execution request The pattern matching process that selects the matching action by matching with the pattern for selecting the action, the action execution process that manages the execution of the selected action, and the event object A computer-readable recording medium having recorded thereon a program for causing a computer to execute a flow control process for selecting and executing an action to be fired next according to a type of a received event object. 10. A program for realizing, by a computer, an apparatus for dynamically determining a data flow by an action chain in event processing in a distributed system, comprising: a message receiving process for receiving a message; and a message transmitting process for transmitting a message. Processing, when the received message is a request to change the definition information about the action, action management processing for changing the definition information about the action, parameter list of the message received as the action execution request,
By matching with the pattern for selecting the action,
Pattern matching processing for selecting a matching action, action execution processing for managing the execution of the selected action, and selection and execution of the next action to be fired depending on the type of the event object that is started when the event object is received A program that determines a dynamic data flow based on an action chain for causing a computer to execute a flow control process for controlling a computer.