CN108140008A - Steel handles the Event Service method and frame system of middleware - Google Patents

Abstract

The Event Service method of steel processing middleware according to the embodiment of the present invention is the Event Service method of the steel processing middleware by mission application software and Events Frame execution, the mission application software includes allowing Application Programming Interface (API) library of task requests Event Service, wherein, this method includes the following steps：Service processor responds Event Service request；Information is defined based on the event for defining event id and size of data to generate event；And if information and the information match of subscription event that pulls subscription about the event generated, the event generated is sent to the subscription task for being mapped to subscription event according to the mapping data of task manager as subscription event.

Description

Event Service Method and Framework System of Steel Processing Middleware

technical field

The disclosure relates to an event service method and a framework system of steel processing middleware.

Background technique

The function of middleware in steel processing control is to perform processing such as storing and referring to information on communication between tasks or information on processing control in response to requests issued by tasks and to manage currently running tasks.

Such tasks may be application software that is solely and exclusively responsible for segmented plant control functions to improve system performance and stability.

Additionally, for collaboration, a task can instruct middleware to create events and can receive events created by another task.

The event service of the steel processing middleware of the related art is processed by sending and receiving messages in a one-to-one communication manner, therefore, when a task has to send an event to a plurality of tasks, an extended processing time may be required.

In addition, the steel processing middleware repeatedly creates/deletes multiple tasks, and when a new collaboration system is added, the event service function of the new collaboration system must be added to the steel processing middleware.

Therefore, there is a need for a framework system to provide developers of steel processing middleware with an environment for developing event service methods and processing and maintaining them according to new collaboration systems.

Contents of the invention

technical problem

An aspect of the present disclosure may provide a framework system configured to increase processing speed of event services of steel processing middleware and optimize processing development and management environments.

Additionally, compatibility is maintained when event services are handled by sending and receiving messages.

Technical solutions

According to an aspect of the present disclosure, an event servicing method of steel processing middleware executed by a task application software including an application programming interface (API) library allowing tasks to issue event service requests and an event framework may be provided. The event service method may include: a service handler responding to the event service request; creating an event based on event definition information defining an event ID and a data size; and if the information about the created event is consistent with the information about the requested subscription event If they are consistent, the created event is sent as the requested subscription event to the subscription task mapped to the requested subscription event according to the mapping data of the event manager.

According to another aspect of the present disclosure, an event service framework system of steel processing middleware may be provided, the event service framework system is implemented by at least one processor and includes task application software and an event framework, and the task application software includes tasks that allow tasks API library for requesting event services including event subscriptions. The event framework may include: a service handler configured to respond to event service requests; an event manager configured to manage event definition information defining event IDs and data sizes and to manage events in which requested subscription events are mapped mapping data to corresponding subscription tasks; and an event dispatch interface, wherein if the information about the event created by the service processor based on the event definition information is consistent with the information about the requested subscription event, the event dispatch interface can send the created The events for are sent to the subscription task as requested subscription events.

Beneficial effect

According to the embodiments of the present disclosure, the event service method and the framework system can improve the processing speed of the event service of the steel processing middleware and provide an efficient processing development and management environment.

Description of drawings

FIG. 1( a ) is a schematic diagram showing an example of an event service of the processing steel processing middleware.

FIG. 1( b ) is a schematic diagram illustrating an event service processing process of an event service framework system using steel processing middleware according to an embodiment of the present disclosure.

FIG. 2 is a block diagram illustrating an event service framework system of a steel processing middleware according to an embodiment of the present disclosure.

3 is a table illustrating an application programming interface (API) library of the event service framework system of steel processing middleware according to an embodiment of the present disclosure.

FIG. 4 is a block diagram specifically illustrating an event framework included in an event service framework system of steel processing middleware according to an embodiment of the present disclosure.

FIG. 5 is a block diagram illustrating an event service framework system of steel processing middleware according to another embodiment of the present disclosure.

FIG. 6 is a block diagram illustrating memory interworking services handled by the framework system shown in FIG. 5 .

FIG. 7 is a flowchart illustrating the memory intercommunication service illustrated in FIG. 6 .

FIG. 8 is a sequence diagram illustrating a process for handling an event creation request in an event service framework system according to an embodiment of the present disclosure.

FIG. 9 is a sequence diagram illustrating a process for processing an event reception request in an event service framework system according to an embodiment of the present disclosure.

Detailed ways

Exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings.

This disclosure may, however, be illustrated in many different forms and should not be construed as limited to the specific embodiments set forth herein.

It will be further understood that the terms "comprising" and/or "comprising" as used herein indicate the presence of stated features or components, but do not exclude the presence or addition of one or more other features or components.

In the following embodiments, the suffix "-er" or "-or" is used to indicate a software or hardware component such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC) that performs certain tasks. However, the suffix "-er" or "-or" is not limited to software or hardware components. Such components with the suffix "-er" or "-or" may be configured to reside on the addressable storage medium or configured to execute on one or more processors. Thus, examples of such components having the suffix "-er" or "-or" may include software components, object-oriented software components, components such as class components and task components, processes, functions, properties, procedures, subroutines , program code segments, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Functionality provided in components with suffix "-er" or "-or" as well as other components may be combined into fewer components or further divided into additional components. In addition, components having a suffix of "-er" or "-or" and other components may be implemented such that the components may execute one or more CPUs in a device or system.

FIG. 1( a ) is a schematic diagram showing an example of an event service processing process of a steel processing middleware, and FIG. 1( b ) is an event showing an event service framework system using a steel processing middleware according to an embodiment of the present disclosure. Schematic diagram of service processing.

Referring to Figure 1(a), steel processing middleware can process event services through a one-to-one communication method.

In detail, when a task (A) sends an event to a plurality of tasks B1 to BN, the middleware creates an event in response to an event creation instruction from task A and sends the event to task B1, and then creates an event in response to the event from task A The instruction creates the event again and sends the event to task B2. This process can be repeated until the middleware sends the event to task BN.

On the contrary, referring to 1(b), in the event processing process of the event service framework system using steel processing middleware according to the embodiment of the present disclosure, task A generates event creation instructions only once, and then the middleware can batch process for All scheduled jobs for Task A.

Therefore, steel processing middleware employing the event service framework system of the embodiments of the present disclosure may have improved event service processing speed.

FIG. 2 is a block diagram illustrating an event service framework system of a steel processing middleware according to an embodiment of the present disclosure.

Referring to FIG. 2 , the steel processing middleware of this embodiment may include task application software 10 and event framework 20 . The task application software 10 may include a plurality of tasks 11 to 1N and an application programming interface (API) library 100 . The event framework 20 may include a plurality of service processors 21 to 2N, an event manager 200 and an event scheduling interface 300 .

In addition, according to the design, the event framework 20 may include at least one of the following: a sent event queue pool 400 , an event service monitor 500 , a framework manager 600 and a storage device 30 .

The plurality of tasks 11 to 1N may be a plurality of application software including steel processing operation logic for operating a level 2 system of steel processing, and each of the tasks 11 to 1N may call an API dedicated to an event service of the event framework 20 to receive event services. Here, the level 2 system for steel processing utilizes tasks 11 to 1N, steel processing middleware, and the level 1, 2 and 3 systems constitute the steel processing automation system.

A level 1 system for steel processing performs unit equipment control, sequence control, and PID control at a low level connected to the production process of the steel plant. To this end, a Level 1 system for steel processing may include a Programmable Logic Controller (PLC), Distributed Control System (DSC), Digital Direct Controller (DDC), sensors, etc.

Furthermore, Level 3 systems for steel processing may be business systems for contract/order management, production/processing management, and quality design, and may include enterprise resource planning (ERP) systems and manufacturing execution systems (MES).

The API library 100 is a set of programming functions that are called according to the request of the tasks that are the main agents that use the middleware service to perform logic processing, and each task can call the corresponding API to request the event framework 20 for each function including the event service. kind of service.

The API library 100 may include an API through which a task may request event services from the event framework 20 including event definition, event subscription, event subscription cancellation, event creation, event reception, and event definition deletion. Specific APIs that the API library 100 may include will be described later according to an embodiment with reference to FIG. 3 .

A plurality of service processors 21 to 2N may be assigned in response to an event service request of the API of the task application software 10 .

The event manager 200 may manage event definition information and may manage data regarding mapping between requested subscription events and corresponding subscription tasks. Herein, the expression "manage something" refers to creating, deleting, and changing that thing. Here, the event definition information includes an event identification (ID) and data information on variable data that can be sent from a task to the event framework 20 (see FIG. 2 ) for processing the event service. Here, the data information may indicate the size of variable data. In addition, the event manager 200 may provide event definition information and mapping data in response to requests from the service processors 21 to 2N.

If a subscription event is created, the event scheduling interface 300 can send the subscription event to a corresponding subscription task according to the mapping data.

The sent event queue pool 400 may include a plurality of sent event queues that wait until a subscription task receives a subscription event sent by the event dispatch interface 300 .

The event service monitor 500 can monitor the event manager 200 , the event dispatch interface 300 and the sent event queue pool 400 to send information about the status of subscribed events to the task application software 10 .

When the event framework 20 is working, the framework manager 600 is created first, and the framework manager 600 can create all components of the event framework 20 after initialization processing, and when the event framework 20 stops working, the framework manager 600 can collect the A resource for framework 20 components.

The storage device 30 can store a setting data list 31 which is file data containing setting values for controlling processing of components of the event framework 20 . In addition, the setting data list 31 may include event system information including event setting values and mapping data about subscribed events and subscribed tasks.

Specific examples of the event manager 200 , the event scheduling interface 300 and the sent event queue pool 400 will be described later with reference to FIG. 4 .

FIG. 3 is a table showing an API library of an event service framework system of steel processing middleware according to an embodiment of the present disclosure.

Referring to FIG. 3 , the API library may include APIs that can request event services, including: event definition, event subscription, event subscription cancellation, event creation, event reception, event definition deletion, specific events for events that have been sent but not yet received number of tasks, task-specific list of events sent but not yet received, task-specific list of subscribed events, event-specific list of subscribed tasks, initialization of sent event queue, addition of event settings, event Deletion of settings, addition of event subscription task settings, deletion of event subscription task settings, and event system settings.

Hereinafter, the functions of the API will be described one by one. The event definition may instruct the event manager (see reference numeral 200 in FIG. 2 ) to create event definition information in an event frame (see reference numeral 20 in FIG. 2 ) for determining collaboration between tasks. Here, the event definition information includes the event ID and data information on variable data that can be sent from the task to the event frame (see reference numeral 20 in FIG. 2 ) for processing the event service. Here, the data information may indicate the size of variable data.

Event subscriptions can instruct the event framework to create information about the subscription events requested by the subscription task. If the information about the created event matches the information about the subscription event, the event framework can send the subscription event to the subscription task.

Event Subscription Cancellation can instruct the event framework to cancel subscriptions to subscription events that are not necessary for the task to perform logic processing.

Event creation can instruct the event framework to create an event based on the event definition information, and send the event ID and related variable data to the subscribing task. Event creation uses the event definition information defined in the event frame by the event definition. That is to say, each event created by the event creation is consistent with one piece of event definition information among the multiple pieces of event definition information created in the event frame, and thus has an event ID and a corresponding data size.

Event receiving may notify the event framework that a subscribing task is in standby mode for receiving subscription events.

Event definition deletion can instruct the event framework to delete the subscription event information and event definition information managed by the event framework.

Task-specific number of events sent but not yet received The event framework may be requested to send the number of events stored in the sent event queue pool (see reference numeral 400 in FIG. 2 ) for subscribing tasks.

A task-specific list of events that have been sent but not yet received can request that the event framework send information about events stored in the sent event queue pool for subscribing tasks.

A task-specific list of subscription events may request the event framework to send information about subscription events that a subscription task has determined to subscribe to.

An event-specific list of subscription tasks may request the event framework to send information about the subscription tasks corresponding to the subscription events.

Initialization of the sent event queue may instruct the event framework to initialize the sent event queue pool by deleting all sent event queues for the sent event queue pool.

The addition of event settings and the deletion of event settings can command the event framework to add event settings to the setting data list (see reference number 31 in FIG. 2 ) stored in the storage device (see reference number 30 in FIG. 2 ). value or delete the event setting value from the setting data list.

Addition of event subscription task settings and deletion of event subscription task settings may instruct the event framework to modify mapping data on subscription events and subscription tasks included in the setting data list stored in the storage device.

The event system sets the system that can instruct the event manager (see reference numeral 200 in FIG. 2 ) of the event framework to rebuild events.

An API library including these APIs can provide an efficient processing development and maintenance environment for developers of steel processing middleware.

FIG. 4 is a block diagram specifically illustrating an event framework included in an event service framework system of steel processing middleware according to an embodiment of the present disclosure.

Referring to FIG. 4 , it shows a specific example of an event manager 200 , an event scheduling interface 300 and a sent event queue pool 400 included in the steel processing middleware event service framework system according to an embodiment of the present disclosure.

The event manager 200 may include an event system access regulator 210 , an event setting data manager 220 , an event definition manager 230 , a subscription task-event mapper 240 and an event-subscription task mapper 250 .

The event scheduling interface 300 may include a temporary standby queue manager 310, a plurality of temporary standby queue access regulators 311, 312 and 313, a plurality of temporary standby queues 321, 322 and 323, an event sender manager 330, a plurality of event sender 331, 332 and 333 and temporary standby queue selector 340.

The sent event queue pool 400 may include a plurality of sent event queue managers 410 , 420 and 430 , a plurality of sent event queue access regulators 411 , 421 and 431 , and a plurality of sent event queues 412 , 422 and 432 .

In FIG. 4, each set of multiple components is shown as having three components. However, this is an example for description and should not be considered for purposes of limitation. For example, the number of components may vary with event framework 20's event service processing. Multiple components within each group may perform the same function, and thus may be described assuming the presence of a single component within each group.

In order to ensure the integrity of event definition information and mapping data in which subscription events are mapped to corresponding subscription tasks, when service processors 21 to 2N add/delete/search event definition information and mapping data, the event system access regulator 210 may The service processors 21 to 2N are authorized to access event definition information and mapping data.

The event setting data manager 220 may obtain or modify event setting values and mapping data about subscribed events and subscribed tasks.

The event definition manager 230 may create event definition information by receiving event setting values acquired by the event setting data manager 220 , or may create or delete event definition information in response to a request from the API of the task application software 10 .

The subscription task-event mapper 240 may manage map data in which task data has priority. That is, the subscription task-event mapper 240 can manage mapping data such that subscription events mapped to the subscription task to be searched can also be searched.

The event-subscription task mapper 250 may manage mapping data in which event data has priority. That is, the event-subscription task mapper 250 can manage mapping data such that a subscription task mapped to a subscription event to be searched can also be searched.

The temporary standby queue manager 310 may create/delete a temporary standby queue 321 temporarily storing events, and may manage information on a state of the temporary standby queue 321 .

Temporary standby queue access regulator 311 may adjust access rights to prevent temporary standby queue manager 310 and event sender 331 from concurrently accessing temporary standby queue 321 , and thus maintain the integrity of subscribed events stored in temporary standby queue 321 .

A temporary standby queue 321 may be created corresponding to the event sender 331 and may temporarily store subscription events. The event sender 331 can send the subscription event to the corresponding subscription task.

The event transmitter manager 330 may create/delete event transmitters 331 and may manage information on the status of the event transmitters 331 .

The temporary standby queue selector 340 acquires information on the status of the temporary standby queue 321 from the temporary standby queue manager 310, and determines the event sender 331 as the event sender that sends the subscription event. Afterwards, the service processors 21 to 2N can store the subscription event in the temporary standby queue 321, and then can request the event transmitter manager 330 to perform transmission processing.

Sent event queue manager 410 may manage information about the status of sent event queue 412 . Sent event queue access regulator 411 may regulate access rights to prevent simultaneous access from service processors and event senders 301 , and thus maintain the integrity of subscription events stored in sent event queue 412 .

The sent event queue 412 can store the subscription events sent by the event scheduling interface 300, so that the subscription events can wait until the subscription task receives the subscription events.

Additionally, such subscribed events may be variable event messages 40 including event IDs and variable data.

FIG. 5 is a block diagram illustrating an event service framework system of steel processing middleware according to another embodiment of the present disclosure.

When compared with the framework system shown in FIG. 2 , the framework system shown in FIG. 5 also includes an API for sending and receiving messages, an interworking interface 700 , a message manager 800 and a memory manager 900 .

Other structures of the frame system can be understood from the description of the frame system provided with reference to FIG. 2 , and thus repeated descriptions thereof will be omitted.

As shown in FIG. 5 , the API library 100 may have an API having a message sending function and a message receiving function so that tasks can send messages to and receive messages from other objects (eg, the event frame 20 ).

In addition, a plurality of service processors 21 to 2N may be allocated in response to an event service request of the API of the task application software 10 . Here, event service requests can be made through APIs such as event subscription or creation, or through message sending or receiving.

In detail, when a message is received from a task 11 to 1N, the service processor 21 to 2N responds to the message, and then the event framework 20 can create an event and send a subscription event.

In addition, the event dispatch interface 300 can send subscription events by converting the subscription events into messages and sending the messages to the subscribing tasks.

That is, when a task 11 to 1N requests event creation, the service processor 21 to 2N can respond to the request, and then the event framework 20 can convert the created event into a message, and can send the message to the subscribed Task.

To this end, the interworking interface 700 connects the service processors 21 to 2N, the event manager 200, the message manager 800, and the storage manager 900 to each other, so that the processes including sending and receiving of messages, creation of events, and sending of subscribed events Event services can be handled interactively. In addition, the message manager 800 can control the sending and receiving of messages according to the instruction of the intercommunication interface 700 .

The memory manager 900 is a component provided by the event framework 20 for a memory interworking service, and will be described below with reference to FIG. 6 .

FIG. 6 is a block diagram illustrating memory interworking services handled by the framework system shown in FIG. 5 .

Referring to FIG. 6, a PLC for unit equipment control is a component included in the steel processing level 1 system, and the memory of the PLC can be monitored by task application software. Task application software can be run upon event service requests, and in this case, information from PLC memory can be included in messages by the API library 100 and then sent to the event framework 20 . Additionally, the message may include a task ID.

The service processor 21 may respond to service requests included in the memory information.

Since the memory information is sent to the event framework 20 in the form of a message, the interworking interface 700 sends the memory information to the message manager 800 to perform the memory interworking service, and the message manager 800 can deliver the memory information to the memory manager 900 .

The memory manager 900 may store memory information of the PLC. If new memory information 920 is sent from message manager 800 to memory manager 900, memory manager 900 may compare new memory information 920 with previously stored memory information 910 to determine whether event criteria are met. In addition, if the event criteria are met, the memory manager 900 may deliver information on the event to be created to the service processor, and may order the event to be created. Thereafter, a service processor that has received information about an event can create an event.

FIG. 7 is a flowchart illustrating the memory intercommunication service illustrated in FIG. 6 .

First, the task application software may detect a change in the memory area of the PLC ( S710 ), and may send a service request to the event framework 20 through the API library 100 . A service request is made by sending a message including memory information about a change in a memory area to the event framework 20 (S720). Afterwards, the service processor responds to the service request (S730).

Next, it is determined whether the service request is a memory intercommunication request (S740), and if the service request is a memory intercommunication request, the memory information is compared with previously stored memory information (S750). If the comparison result does not meet the event standard, the memory information is updated (S754), and if the comparison result meets the event standard, it is determined as an event service (S760).

If it is determined as an event service, an event creation request may be made to send a subscription event (S770), and if it is not determined to be an event service, message processing may be performed to send a message (S780).

FIG. 8 is a sequence diagram illustrating a process for handling an event creation request in an event service framework system according to an embodiment of the present disclosure. The processing shown in Figure 8 is a non-limiting example.

Referring to FIG. 8, if a task requests a service handler for an event service to create an event (S510), the service handler may request the event definition manager to send event definition information (S531), and may receive a response to the event definition information request (S531). S532). Alternatively, in order to ensure the data integrity of the event definition information, the service processor may request access to the event definition information from the event system access regulator before requesting the event definition information (S521), and may obtain permission to access the event definition information (S521). S522).

The service processor uses the event definition information to create an event with information consistent with one of the event definition information.

In addition, the service processor requests the temporary standby queue selector to allocate a standby queue (S541). Then, the temporary standby queue selector may request standby queue information from the temporary standby queue manager (S542), and may receive a response to the standby queue information request (S543). The temporary standby queue selector may obtain status information about the temporary standby queue from a response to the pending queue information request, and may determine an event sender that will send subscribed events. Afterwards, the temporary standby queue selector may reply to the service processor that the standby queue has been allocated (S544).

After receiving a reply reporting completion of the standby queue allocation, the service processor may store the requested created event as a subscribed event in the temporary standby queue. Afterwards, the service processor may request the event sender manager to process the subscription event (S561) and may receive a subscription event processing response (S562). In addition, since the service processor and the event sender can access the temporary standby queue at the same time, in order to ensure the data integrity of the temporary standby queue, the service processor can send the requested event to the The temporary standby queue access manager requests access to the temporary standby queue (S551), and may obtain permission to access the temporary standby queue (S552).

After receiving the subscription event processing response, the service processor may reply to the task that the event has been created (S570).

In addition, after subscribing to the event processing response, the event sender manager may request the event sender to perform sending processing (S580).

Therefore, according to an embodiment of the present disclosure, the event service framework system can store subscription events that can be sent in batches in response to a one-off event creation request, and can reply that an event has been created. Therefore, it is possible to reduce the response waiting time in which the task waits for the event creation to be completed after the event creation is requested.

FIG. 9 is a sequence diagram illustrating a process for processing an event reception request in an event service framework system according to an embodiment of the present disclosure. The processing shown in Figure 9 is a non-limiting example.

Referring to FIG. 9, if a task requests an event service to a service handler to receive an event (S610), the service handler may request the sent event queue access regulator to check a subscription event (S621) and may receive a subscription event response. If there is no corresponding subscription event, that is, if the event sender is waiting for a scheduling request, the sent event queue access regulator may reply to the subscription event check request that there is no subscription event (S622).

As described with reference to FIG. 8, if the event sender manager requests the event sender to perform a send process (S580), the event sender may adopt a subscription event stored in a temporary standby queue. This can be performed by replicating information and data about subscription events. In addition, in order to ensure the data integrity of the temporary standby queue, the service processor can request access to the temporary standby queue from the temporary standby queue access adjuster (S631) before adopting the subscription event, and can obtain permission to access the temporary standby queue (S632) .

Next, the event sender may request access to the sent event queue from the sent event queue access regulator (S641), and may obtain permission to access the sent event queue (S642).

Afterwards, the event sender may store the subscription event in the sent event queue, and may send the status of the stored subscription event to the sent event queue access regulator (S650).

After the subscription event is stored in the sent event queue, the sent event queue access regulator may notify the service processor of the subscription event (S660).

Also, if the service processor requests the sent event queue access regulator to check the subscribed events (S621'), the sent event queue access regulator may reply affirmatively to the service processor (S670).

Next, the service processor may transmit an event reception reply to the event reception request (S680). That is, tasks that have requested event reception can receive subscribed tasks.

While embodiments of the present disclosure have been shown and described above with reference to the accompanying drawings, the scope of the invention is not limited thereto and it will be apparent to those skilled in the art that the invention may be implemented without departing from the scope of the appended claims. Modifications and changes are made within the scope of the present invention.

Claims (14)

1. a kind of Event Service method of steel processing middleware, the Event Service method is by mission application software and Events Frame It performs, the mission application software includes Application Programming Interface (API) library that permission task sends out Event Service request, the thing Part method of servicing includes：

Service processor responds Event Service request；

Information is defined based on the event for defining event id and size of data to create event；And

If the information about the event created is consistent with the information about requested subscription event, by reference to event The event created as requested subscription event is sent to and is mapped to requested subscription thing by the mapping data of manager The subscription task of part.

2. Event Service method according to claim 1, wherein, the establishment of event includes：

If the Event Service request includes memorizer information, memory manager is by the memorizer information with previously depositing The memorizer information of storage is compared, to determine whether to meet event criteria；And

If meeting the event criteria, the service processor is determined based on the event for defining event id and size of data Adopted information creates event.

3. Event Service method according to claim 1, wherein, using the event created as requested subscription event Be sent to the subscription task be by via event scheduling interface send requested subscription event be performed or Requested subscription event is converted into what is performed after message.

4. Event Service method according to claim 3, wherein, the event scheduling interface includes：

Event transmitter is configured to the subscription event being sent to subscription task corresponding with the subscription event；With And

The interim queue of awaiting orders accordingly created with the event transmitter, the interim queue of awaiting orders is for described in interim storage Subscription event.

5. Event Service method according to claim 1, wherein, the task manager includes：

Event defines manager, is configured to create and deletes the event and defines information；

Subscription task-Event mapper, being configured to management wherein task data has the mapping data of priority；And

Event-subscription task mapper, being configured to management wherein event data has the mapping data of priority.

6. a kind of Event Service frame system of steel processing middleware, the Event Service frame system is by least one processor It realizes and including mission application software and Events Frame, the mission application software sends out Event Service including permission task please The API library asked, the Events Frame include：

Service processor is configured to respond Event Service request；

Task manager, the event for being configured to management definition event id and size of data define information, and manage wherein Information about requested subscription event is mapped to the mapping data of corresponding subscription task；And

Event scheduling interface, wherein, if about the event for defining information creating based on the event by the service processor Information it is consistent with the information about requested subscription event, then the event scheduling interface is using the event created as institute The subscription event of request is sent to subscription task.

7. Event Service frame system according to claim 6, further includes memory manager, wherein, if the thing Part service request includes memorizer information, then the memory manager is by the memorizer information and previously stored memory Information is compared, to determine whether to meet event criteria and order establishment event.

8. Event Service frame system according to claim 6, further include message manager, the message manager by with It is set to and the subscription event is converted into message described in information and sending.

9. Event Service frame system according to claim 6, wherein, the API library provides API, and task passes through described API request Event Service, the Event Service include：For creating the event definition, event subscription, event that event defines information Event establishment, event reception and the event definition for subscribe to cancellation, information being defined based on event are deleted.

10. Event Service frame system according to claim 6, wherein, the task manager includes：

Event defines manager, is configured to create and deletes the event and defines information；

Subscription task-Event mapper, being configured to management wherein task data has the mapping data of priority；And

Event-subscription task mapper, being configured to management wherein event data has the mapping data of priority.

11. Event Service frame system according to claim 6, wherein, the Events Frame further includes the event of transmission Queue pond, the event queue pond that sent have sent event queue including multiple, have been ordered by what the event scheduling interface was sent Read event it is described sent wait until that subscription task receives the subscription event in event queue until.

12. Event Service frame system according to claim 11, wherein, the Events Frame further includes Event Service prison Survey device, the Event Service monitor is configured to monitor the task manager, the event scheduling interface and described has sent out Event queue pond is sent, the mission application software will be sent to about the information of the state of the subscription event.

13. Event Service frame system according to claim 6, wherein, the event scheduling interface includes：

Event transmitter is configured to the subscription event being sent to subscription task corresponding with the subscription event；With And

The interim queue of awaiting orders accordingly created with the event transmitter, the interim queue of awaiting orders is for described in interim storage Subscription event.

14. Event Service frame system according to claim 13, wherein, the event scheduling interface further includes to be treated temporarily Queue selector is ordered, the interim queue selector of awaiting orders is configured to the event transmitter that selection sends the subscription event.