[go: up one dir, main page]

WO1999018503A1 - Distributeur d'evenements - Google Patents

Distributeur d'evenements Download PDF

Info

Publication number
WO1999018503A1
WO1999018503A1 PCT/SE1998/001777 SE9801777W WO9918503A1 WO 1999018503 A1 WO1999018503 A1 WO 1999018503A1 SE 9801777 W SE9801777 W SE 9801777W WO 9918503 A1 WO9918503 A1 WO 9918503A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
distributor
queue
representative
representative item
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/SE1998/001777
Other languages
English (en)
Inventor
Erik Ackander
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to AU94682/98A priority Critical patent/AU9468298A/en
Publication of WO1999018503A1 publication Critical patent/WO1999018503A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/544Remote

Definitions

  • the present invention relates to techniques for distributing events within computer software environments, and more particularly to systems and techniques for efficiently distributing events and/or jobs to multiple different subscribing processes within distributed, object-oriented environments. Still more particularly, this invention relates to an Event Distributor for event- based execution handling that holds a queue of Event-subscriber representatives and distributes tasks/jobs to different subscribers based on the Event-subscriber representatives.
  • Event driven software environments perform processing tasks based on '"events.
  • These "events” can be real time occurrences such as sensor outputs in a real time system, or they can be generated by software and/or hardware processes within the environment. Different types of processes may be concerned with different events. For example, a telephone switch '"connection” process might be concerned with “connect “ events, whereas a “disconnection” process might be concerned with “disconnect” events ⁇ and both processes might be concerned with certain common events such as “reset” and "halt.”
  • Event-driven operating systems and platforms typically provide a service that delivers event notifications to "subscriber" processes.
  • Distributing events to subscriber processes can be relatively straightforward in non-distributed environments where each event has only a single natural receiver process.
  • one typical approach provides an event queue for temporarily holding an event until it can be processed by its associated subscriber process.
  • the events can. for example, be queued at the source of the event for distribution to associated subscriber(s).
  • the present invention provides an event distributor for distributing events to subscribers.
  • the event distributor includes an event queue that temporarily holds event notifications; and a further, "representative item” queue that stores “representative items” providing subscriber-specific information.
  • the event distributor distributes the event to at least one subscriber based, at least in part, on an associated "representative item.”
  • the "representative item” may define or include a software function specifying how to communicate with the subscriber.
  • the event distributor may call this software function and pass it the event type as a parameter - thus communicating the event to the subscriber.
  • the event distributor may include a "next indicator" used to reference representative items.
  • An interative approach may use the "next indicator” to refer, in a sequence, to each "representative item " on the "'representative item " queue.
  • the "representative items” can include filters that selectively pass or not pass particular events to corresponding subscribers.
  • the event distributor can itself be distributed in the form of two or more instances. Different instances of the event distributor can provide different event-driven functionality such as. for example, "in service” versus “initialization. " A subscriber can be shifted from one event distributor instance to another simply by moving the subscriber ' s corresponding representative item.
  • One event distributor can. instead of deleting events after distributing them, send them to another event distributor to distribute (or not. depending on the particular functionality) them to other subscribers.
  • the event distributor can distribute events to plural subscribers of different types within a distributed, object oriented environment.
  • the representative item queue may store plural representative items for each of corresponding, multiple subscribers.
  • Each representative item may includes a function to reach a corresponding subscriber.
  • Figure 1 shows an example event distributor
  • Figure 2 shows an example simplified process performed by the Figure 1 event distributor
  • Figure 3 shows an example event distributor representative item insertion process
  • Figure 4 shows an example event distributor event insertion process
  • Figure 5 shows an example distributed event distributor arrangement
  • Figures 6A and 6B show example representative item insertion and event distribution processes for the Figure 5 distributed event distributor arrangement:
  • Figure 7 shows an example acknowledgment process.
  • FIG. 1 shows an example event distributor 10.
  • event distributor 10 distributes events 14 to event subscribers 15.
  • An event (E) 14 is generated in this environment when something happens that needs action to be taken.
  • Event subscribers 15 may respond to events 14 by performing jobs or tasks associated with the events. Different event subscribers 15 may perform the same or different processes in response to a given event 14.
  • event distributor 10 is adapted for use with a distributed, object-oriented software environment in which execution handling is event based.
  • Event subscribers 15 may be, for example, software objects executing on a single computer or in a distributed fashion on any number of cooperating inter-networked computers.
  • the environment can. for example, dynamically create and destroy some or all event subscribers 15 at run time.
  • Event subscribers 15 may have the typical characteristics of "objects " within an object-oriented environment - including the ability to "inherit " certain behavior from another object or object class.
  • the subscribers 15 can be of any software type.
  • event distributor 10 includes an event queue 12 that temporarily holds notifications of events 14 until they can be handled.
  • Each event (E) 14 notification may specify event type.
  • Event 14 notification ma ⁇ also hold an a ⁇ ribute list.
  • the attribute list is typically specified per event type so that responding processes can interpret the attributes.
  • event distributor 10 holds a further queue 16. This further queue 16 may be called the "representative item " queue.
  • Representative item queue 16 holds event-subscriber "'representative items" 18.
  • Each representative item 18 may correspond with an associated subscriber 15. For example, representative item 18(1) may correspond to subscriber 15(1). representative item 18(2) may correspond to subscriber 15(2). and so on.
  • the representative items (RI) 18 hold or provide data specifying one or more functions to reach an associated represented subscriber 15.
  • the event distributor 10 can distribute the notification of an event 14 to a particular subscriber 15 by calling the function of the representative item 18 associated with the subscriber and passing the event notification to that representative item function.
  • the representative item 18 function may then perform the task of communicating the event notification to the associated subscriber 15. Since subscribers 15 can have different characteristics in this example, they all need not receive and respond to the same events 14. For example, certain subscribers 15(1) may subscribe to certain events (e.g., 14(1)) but not other events (e.g.. 14(2)). Other subscribers 15(2) may subscriber to different events (e.g.. 14(2) but not 14(1)).
  • event distributor 10 can pass each event 14 to each representative item 18 - and the representative items 18 may filter or select which events 14 to pass to their corresponding subscribers 15.
  • the representative items 18 can be "marked” with attributes that indicate whether certain events are to be passed to their corresponding subscribers.
  • the representative items 18 may themselves be objects that "inherit" a communications function to reach a corresponding subscriber 15.
  • representative items 18 may be inherited communications functions that accept an event type as a parameter. Such "inherited" communications functions may include, for example, a filter to select which events 14 to pass to the associated subscriber 15. as well as communications information (e.g., an IPC address) specifying how to reach the subscriber.
  • Representative items 18 can specify additional information relating to how to communicate with an associated subscriber such as, for example, how to format or convert event related parameters to make them compatible with inputs the subscriber is capable of receiving and processing.
  • event distributor 10 also provides a " next indicator" 20.
  • "Next indicator” 20 indicates a selected one of representative items 18 to be handled next.
  • queues 12. 16 are implemented as linked lists, and the "next indicator" 20 is updated with the corresponding linked list pointer as event distributor 10 traverses the representative item linked list queue 16.
  • Figure 2 shows an example simplified process the Figure 1 event distributor 10 may perform to distribute events 14.
  • event distributor 10 determines whether there is an event on event queue 12 (decision block 30). If not, the event distributor 10 may remain idle while waiting for an event. Once an event 14 appears on event queue 12, event distributor 10 looks at the first event on the event queue and calls the first representative item 18 in the item queue 16 with the event ( Figure 2, block 32). For example, event distributor 10 may call the representative item 18 communications function, passing that function the event type (and any event parameters) specified by the corresponding event 14. The representative item 18 then performs the function of sending the event 14 to its corresponding subscriber 15 ( Figure 2. block 32).
  • Event distributor 10 may next update the "next indicator" 20 to reference the next representative item 18 on item queue 16 ( Figure 2, block 34). Event distributor 10 now repeats block 32 for all representative items 18 on item queue 16. When event distributor 10 has passed the event to all subscribers as specified by corresponding representative items 18 ( Figure 2. decision block 36). the event distributor removes the event from the event queue 12 and resets the "next indicator" 20 to a first representative item 18 on item queue 16 ( Figure 2, block 38). Event distributor 10 may now repeat blocks 30-38 with the next event (if any) 14 on event queue 12 until there are no more events in the event queue. At this point, event distributor 10 returns to the idle state and waits for a new event (Figure 2, decision block 30).
  • Figures 3 and 4 show more detailed example representative item insertion and event insertion processes performed by event distributor 10. These more detailed processes will be explained in conjunction with an example in which a network user (e.g., a computer using a data network) wishes to subscribe to an event "NetworkStateChange" indicating whether or not the network is working.
  • a network user e.g., a computer using a data network
  • the network user wishes to receive network state working/not working information.
  • a representative item 18 that holds functions to reach the network user with the event "NetworkStateChange" ( Figure 3, block 40).
  • the new representative item 18 is inserted last on the event distributor 10 " s item queue 16 ( Figure 3. block 42). If the new representative item 18 happens to be the first (only) representative item on item queue 16, then the "next indicator" 20 is set to reference the new representative item ( Figure 3. blocks 48, 50).
  • the newly inserted representative item 18 needs a "current" state as an initialization event ("InitEvent") upon insertion in order to synchronize the user process with the current state of the network as being working or not working.
  • Such an initialization event may be sent to the user process via its newly created representative item 18 as described above ( Figure 3, blocks 44, 46). Since representative items 18 can be of different types, initialization events are. in this example, specified per representative item type.
  • the new representative item 18 will receive that event (e.g.. event type "'NetworkStateChange”. state: working/not working) through performance of the event insertion steps shown in Figure 4.
  • the representative item 18 "knows" how to reach the user process (e.g.. it may be or provide a pointer to an IPC-port object corresponding to the user process) and distributes the event notification information using any format decided when designing the representative item 18 (this format may correspond to a particular format the corresponding user process is expecting).
  • Representative item 18 may inherit the characteristic of receiving all events 14; however, only the events the corresponding subscriber 15 has subscribed on are implemented, to be distributed on to the network process by the representative item 18.
  • Figure 4 shows an example event insertion process.
  • the event "new- user”, with the parameters "name” and "address”, may be inserted onto the event distributor's event queue 12 as a new event.
  • the event distributor 10 determines whether its item queue 16 is empty ( Figure 4, decision block 60). If the item queue is empty ("yes" exit to decision block 60), then there are no active processes to distribute the event to and the event can be immediately deleted ( Figure 4, block 62). If. on the other hand, item queue 16 is not empty (""no " exit to decision block 60). then event distributor 10 determines whether the event queue 12 is empty ( Figure 4, decision block 64). If event queue 12 is not empty ("no" exit to decision block 64). then the event distributor 10 is already working to distribute another event ⁇ and the new event is inserted onto event queue 12 for processing as soon as the event distibutor finishes processing other events previously placed on the event queue ( Figure 4. block 66).
  • event distributor 10 is currently waiting for a new event. In this case, the new event is inserted onto the event queue 12 ( Figure 4. block 68). and additional processes shown in Figure 4. blocks 70-80 are performed to distribute the event to subscribers 15.
  • the event distributor 10 first distributes the event to the subscriber 15 corresponding to the representative item 18 referenced by the ""next indicator" 20 ( Figure 4. block 70).
  • block 70 involve calling a function defined by this referenced representative item 18. and passing it the event type plus any associated event parameters (e.g., event type: "new user " : event parameters "name” and "address " ). While an address might be represented in different formats for different user types, the event 14 always uses the same predefined address format in this example — the proper conversion being done by the representative item 18 before passing the event on to the subscriber.
  • the example process then "steps" "next indicator" 20 to refer to the next representative item 18 on item queue 16 (block 72).
  • event distributor 10 continues iteratively until event distributor 10 has distributed the event to all required subscribers 15 via all representative items 18 that are present on item queue 16 (as tested for by decision block 74). Once event distributor 10 has passed the event via all representative items 18 ("yes" exit to decision block 74). event distributor 10 may delete the event from event queue 20 (inserting it into any sub-event distributor event queue at this time, as discussed below) ( Figure 4, block 76). Event distributor 10 next preferably resets the "next indicator" 20 to the first representative item 18 on item queue 16 ( Figure 4, block 78) and then determines whether the event queue 12 is empty ( Figure 4, block 80).
  • event distributor 10 If the event queue is now empty' ("yes" exit to Figure 4, decision block 80), event distributor 10 returns to an idle state ( Figure 4, block 82). Otherwise, event distributor 10 repeats blocks 70-78 for the next event - and for all events on event queue 12. Not shown in Figure 2 are details such as acknowledging every event sent, providing time stamps in events, or having representative items 18 with only some event types implemented. Such additional functionality can be provided if desired.
  • Event Distributed Event Distributors An extension to the arrangements described above provides multiple instances of event distributors 10. Such event distributor 10 multiple instances may, for example, be distributed within the same computer or within different inter-networked computers. The multiple instances of event distributors 10 can cooperate with one another to each perform the overall function of distributing events 14 to subscribers 15. Sub-event distributor 10' could communicate events to a sub-sub-event distributor, or event distributor 10 could communicate different or the same events to multiple sub-event distributors.
  • Figure 5 shows an example arrangement including an event distributor 10 and a sub-event distributor 10'.
  • event distributor 10 distributes new event 14 to subscribers 15 based on representative items 18a. 18b, as described above.
  • event distributor 10 removes the event from its own event queue 12 and inserts it as event 14' onto an event queue 14' of a sub-event distributor 10'.
  • Sub-event distributor 10' has its own representative item queue 16' holding representative item 18c.
  • Sub-event distributor 10 ' distributes event 14' to a different subscriber 15c (not shown) via representative item 18c.
  • Sub-event distributor 10' may, for example, distribute event 14' under certain conditions in which it is not efficient or desirable for event distributor 10' to distribute the event 14. For example, sub-event distributor 10 ' may have a lower priority (in the meaning of receiving events later). Thus, instead of deleting an event 14 after it has been distributed ( Figure 2. block 38), event distributor 10 may insert it as event 14' onto the event queue 12' of sub-event distributor 10'.
  • event distributors One way to create event distributors with somewhat different functions is to have them inherit base functions of the event distributor, and then specialize their behavior to provide a sub-event distributor or any other wanted event distributor event behavior. As one particular example in which such distributed event distributors
  • Figure 5 shows that event distributor 10 acts as a run time handler to distribute events 14 to all currently "in service " subscribers 15; whereas event distributor 10' acts as an initializer to distribute events 14 " to subscribers 15 that have been started but are not yet in service.
  • Figure 5 shows a representative item 18c corresponding to a "router" subscriber 15.
  • a "router” is an object that chooses a route for a message with a specific address to be sent on. Routers typically include routing tables that are dynamically updated to specify the specific address. Router processes may possibly run on different processors, and may possibly be of different types that need to dynamically update routing tables.
  • the Figure 5 arrangement is particularly advantageous for use in this context.
  • Global system states and initial routing tables may be set up based on a distributed database or other techniques that ensure consistency of global states.
  • the routing tables can be based on static information (predefined), and treated as an initialization event to be distributed to the router when the router starts.
  • static information predefined
  • the states and initial routing tables may typically depend on what the overall network or environment looks like right now, there are possibly delay problems that may arise because it takes a certain amount of time to distribute the required initialization events to the router. Therefore, it may be desirable to use a sub- event distributor 10' to handle the router initialization phase.
  • router software processes of type A corresponding to representative items 18a. 18b on the event distributor's item queue 16
  • Event distributor 10 informs these corresponding subscribers of state change events as they occur via type A representative items 18a, 18b connected to event distributor 10.
  • a newly created "router" subscriber of type A holds a state machine function and initially needs to be informed of some system global states before it is taken into service.
  • the "router" creation process results in creating a type A- representative item 18c.
  • This representative item 18c is connected to event distributor 10' ("intializer") ⁇ which is responsible for initializing the router with all relevant system global states.
  • This initialization process which is performed by passing initialization events to the router ⁇ may take some time. Suppose that during the time the router is being initialized, a new event (a state change) occurs that is subscribed to by all type A subscribers.
  • This new event 14 is inserted onto the event distributor event queue 12, and is passed on to the already-in-service type A subscribers via representative items 18a, 18b.
  • event distributor 10 removes the event 14 from its own event queue 12, and inserts it onto the event queue 12' of the sub-event distributor 10'.
  • Event distributor 10' may possibly now distribute the event 14' to the newly created router process before removing and deleting the event from its own event queue 12'. Whether or not sub- event distributor 10' does distribute this event to the newly created router undergoing initialization may depend, for example, on the chosen initializing algorithm. The goal may be, for example, to prevent the router from missing any events while it is undergoing initialization by having the event distributor 10 sending the event to the sub-event distributor 10' instead of deleting the event.
  • the representative item 18c corresponding to the router may be removed from the sub-event distributor item queue 16' and connected instead to the event distributor 10 item queue 16 (this is indicated by the line 24 shown in Figure 5). This has the effect of placing the router into service. Any events received by event distributor 10 will now be passed to the newly-placed-in- service router via its corresponding representative item 18c on representative item queue 16.
  • Figures 6A, 6B and 7 show an example of a specialized representative item, event distribution and acknowledge example processes that might be used with the specific example shown in Figure 5.
  • These specialized example processes may provide inherited representative item functionality that makes use of a "sub-phase indicator” attribute that the event distributor uses to selective pass (or not pass) events to subscribers based on whether the events correspond to a certain "sub-phase” in an overall initialization process.
  • event handling is split up into two "sub- phases.” For example, sub-phase one might distribute events pertaining to routing destinations and corresponding routes, while sub-phase two may distribute system global state events.
  • the distributed event handling arrangement can, in this example, distribute a certain amount of data to the router (e.g., "sub-phase one": routing table contents right now) and then wait for an acknowledgment from the representative item (subscriber) before distributing "sub-phase two" events (e.g., data in a local database or process memory).
  • One sub-phase could, for example, include one or more events or possibly, specially designed buffers holding chunks of data including all system global states affecting the routing table such as information from many earlier events (e.g., loading down many variables, each earlier updated by events).
  • events within sub- phase one are distributed ( Figure 6A. block 104)
  • the sub-event distributor 10' marks a "sub-phase indicator" switch provided by the representative item 18 with an indication that phase one is complete ( Figure 6A. block 104).
  • the sub-event distributor 10' then enters the idle state ( Figure 6A. block 106) and waits for an acknowledgement.
  • the most simple version of the event distributor is stateless so state IDLE represents "let go of execution thread " (while in some cases it may be desirable to save events in the event queue until the first representative item is inserted, that would not be done in this particular, more simple, example).
  • event distributor 10 recei ⁇ es an event indicating that one of the states has changed ( Figure 6B. block 1 10).
  • the event is processed by event distributor 10, and the event is deleted ( Figure 6B. blocks 1 18. 120).
  • This event is not distributed to the router since it does not affect the sub-phase marked in the sub-phase indicator of representative item 18c (the event would have been distributed if it affected data from sub-phase one and was thus classified as a "'sub-phase one" event).
  • the router process sends an acknowledgment that it received the data properly (Figure 7, block 130).
  • the process looks into the representative item 18c sub-phase indicator and determines that phase one has been done ( Figure 7, decision block 132). This means that is now- necessary to distribute sub-phase two events and mark the representative item to indicate that sub-phase two is also done ( Figure 7, block 134).
  • the network process will acknowledge receipt of the sub-phase two data (block 130, Figure 7).

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Multi Processors (AREA)

Abstract

Le distributeur d'événements réparti en environnement orienté objet de la présente invention a pour fonction de distribuer des événements à des abonnés. Il comporte une file d'attente de données caractéristiques permettant de garder trace des données caractéristiques correspondant aux abonnés. Ces données caractéristiques fournissent des informations se rapportant aux abonnés, par exemple une fonction permettant d'atteindre un abonné correspondant. Pour distribuer les événements à un nombre quelconque d'abonnés, le distributeur d'événements se base sur les données caractéristiques correspondantes de la file d'attente de données caractéristiques. Une logique récursive peut utiliser un indicateur de suite pour l'accès, dans une suite, à chacune des multiples données caractéristiques d'une file d'attente correspondant à autant d'abonnés. Ce distributeur d'événements peut distribuer l'événement à un distributeur de sous-événements qui distribue alors l'événement aux abonnés. Des structures réparties de distribution d'événements permettent d'assurer différentes fonctions. En outre, les abonnés peuvent être transférés d'un distributeur d'événements à un autre. Il suffit pour cela de transférer leurs données caractéristiques correspondantes.
PCT/SE1998/001777 1997-10-06 1998-10-02 Distributeur d'evenements Ceased WO1999018503A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU94682/98A AU9468298A (en) 1997-10-06 1998-10-02 Event distributor

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US94476797A 1997-10-06 1997-10-06
US08/944,767 1997-10-06

Publications (1)

Publication Number Publication Date
WO1999018503A1 true WO1999018503A1 (fr) 1999-04-15

Family

ID=25482038

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE1998/001777 Ceased WO1999018503A1 (fr) 1997-10-06 1998-10-02 Distributeur d'evenements

Country Status (2)

Country Link
AU (1) AU9468298A (fr)
WO (1) WO1999018503A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2361555A (en) * 2000-04-17 2001-10-24 Apama Inc Method of evaluating queries against received event information
WO2001014959A3 (fr) * 1999-08-16 2002-11-07 Force Corp Z Systeme d'unites logicielles reutilisables et procedes d'utilisation
GB2501180B (en) * 2011-01-28 2020-06-17 Hewlett Packard Development Co Distributing information

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5010482A (en) * 1987-07-02 1991-04-23 Unisys Corp. Multi-event mechanism for queuing happened events for a large data processing system
EP0528222A2 (fr) * 1991-08-12 1993-02-24 International Business Machines Corporation Notification de programmes de traitement d'évènements en mode diffusion ou propagation par des services de gestion d'évènements dans un système d'ordinateur
WO1995031781A1 (fr) * 1994-05-13 1995-11-23 Apple Computer, Inc. Procede et appareil de distribution de messages d'evenements dans un systeme d'exploitation
US5548760A (en) * 1993-11-11 1996-08-20 International Computers Limited Message handler
EP0759591A1 (fr) * 1995-08-18 1997-02-26 International Business Machines Corporation Service de gestion d'événements

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5010482A (en) * 1987-07-02 1991-04-23 Unisys Corp. Multi-event mechanism for queuing happened events for a large data processing system
EP0528222A2 (fr) * 1991-08-12 1993-02-24 International Business Machines Corporation Notification de programmes de traitement d'évènements en mode diffusion ou propagation par des services de gestion d'évènements dans un système d'ordinateur
US5548760A (en) * 1993-11-11 1996-08-20 International Computers Limited Message handler
WO1995031781A1 (fr) * 1994-05-13 1995-11-23 Apple Computer, Inc. Procede et appareil de distribution de messages d'evenements dans un systeme d'exploitation
EP0759591A1 (fr) * 1995-08-18 1997-02-26 International Business Machines Corporation Service de gestion d'événements

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001014959A3 (fr) * 1999-08-16 2002-11-07 Force Corp Z Systeme d'unites logicielles reutilisables et procedes d'utilisation
GB2361555A (en) * 2000-04-17 2001-10-24 Apama Inc Method of evaluating queries against received event information
GB2501180B (en) * 2011-01-28 2020-06-17 Hewlett Packard Development Co Distributing information

Also Published As

Publication number Publication date
AU9468298A (en) 1999-04-27

Similar Documents

Publication Publication Date Title
EP0760131B1 (fr) Procede et appareil de distribution de messages d'evenements dans un systeme d'exploitation
EP0797798B1 (fr) Procede et appareil pour la mise a jour ou la modification d'un repertoire de reseau
JP3782477B2 (ja) オペレーティングシステムのシステム管理のためのイベントアーキテクチャ
US5367681A (en) Method and apparatus for routing messages to processes in a computer system
US8788580B2 (en) Event broker for an improved application server platform for telecom-based applications
CN109968352B (zh) 一种机器人控制方法及机器人、具有存储功能的装置
US5341499A (en) Method and apparatus for processing multiple file system server requests in a data processing network
US6212573B1 (en) Mechanism for invoking and servicing multiplexed messages with low context switching overhead
US8032895B2 (en) Inter process communication in a computing device
EP2034408A2 (fr) Service de sondage centralisé
WO2001013271A1 (fr) Systeme et procede de transmission de contenu d"information dans un reseau informatique
CN101325561A (zh) 一种处理电子邮件的方法、装置及系统
US5960178A (en) Queue system and method for point-to-point message passing having a separate table for storing message state and identifier of processor assigned to process the message
KR20250026318A (ko) 다수의 모듈들 및 공유 메모리를 갖는 통신 시스템 노드
US7703103B2 (en) Serving concurrent TCP/IP connections of multiple virtual internet users with a single thread
CN1791102B (zh) 网络下载装置
US6115734A (en) Method of dynamically allocating tasks to events arriving on a set of queues
US8141103B2 (en) Solution for modifying a queue manager to support smart aliasing which permits extensible software to execute against queued data without application modifications
WO1999018503A1 (fr) Distributeur d'evenements
CN111240760A (zh) 基于注册中心的应用发布方法、系统、存储介质及设备
WO1999034557A1 (fr) Procede et systeme permettant de gerer les differentes versions d'un logiciel dans un systeme de gestion de reseau
CN111338821B (zh) 一种实现数据负载均衡的方法、系统及电子设备
CN115051981B (zh) 一种基于Zookeeper的异步下载方法及装置
CN111666090B (zh) 一种应用系统扩展组件在线更新支撑系统
US6459786B1 (en) Call and connection control

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: KR

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA