WO1999018503A1

WO1999018503A1 - Event distributor

Info

Publication number: WO1999018503A1
Application number: PCT/SE1998/001777
Authority: WO
Inventors: Erik Ackander
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 1997-10-06
Filing date: 1998-10-02
Publication date: 1999-04-15
Also published as: AU9468298A

Abstract

A distributed, object oriented environment event distributor for distributing events to subscribers includes a representative item queue storing representative items corresponding to subscribers. The representative items provide subscriber information (e.g., a function to reach a corresponding subscriber). The event distributor distributes events to any number of subscribers based on corresponding representative items on the representative item queue. An iterative approach may use a next indicator to access, in a sequence, each of multiple representative items on a queue corresponding to multiple corresponding subscribers. The event distributor may distribute the event to a sub-event distributor that then distriubtes the event to subscribers. Distributed event distribution arrangements may provide different functionality - and subscribers can be moved from one event distributor to another by moving their corresponding representative items.

Description

EVENT DISTRIBUTOR

Field of the Invention

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.

Background of the Invention

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."

Just as different people subscribe to different magazines or newspapers that interest them, processes within an event driven-environment can be said to "subscribe" to notifications of the particular events they are concerned with. 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. For example, 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).

As the Internet and other networks have become pervasive, it has become increasingly desirable to distribute object-oriented software environments across multiple, cooperating inter-networked computers. Unfortunately, event distribution solutions as described above in connection with non-distributed environments are inefficient and/or unworkable in distributed, object-oriented environments. For example, an important advantageous feature of object-oriented systems are their ability to flexibly (often dynamically) create (and destroy) multiple instances of an object class ~ with each instance "inheriting" appropriate behavior. Unfortunately, the particular known solutions described above typically require all subscribing processes to be of the same type - whereas any type of subscriber can inherit appropriate behavior in an object- oriented environment. Further, such known solutions generally do not make it possible to subscribe/unsubscribe at run time - whereas distributed, object- oriented systems may require new subscribers to be dynamically added and deleted during execution. Thus, it would be highly desirable to provide an efficient technique for distributing events/jobs to different subscribers in a distributed, object-oriented software environment.

Brief Summary Of The Invention

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." In one example, 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.

Additional features and advantages provided by the present invention include the following: • 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.

• Representative items can be dynamically created and deleted as needed.

• Can be used for equal receivers as well as for non-equal receivers via inheriting appropriate behavior. Brief Description Of The Drawings

These and other objects and advantages of this invention, will be more completely understood and appreciated by careful study of the following more detailed description of presently preferred example embodiments of the invention in conjunction with the accompanying drawings, of which:

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: and

Figure 7 shows an example acknowledgment process.

Detailed Description Of Example Embodiments

Figure 1 shows an example event distributor 10. In this example, 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.

In this example, 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. In this example, the subscribers 15 can be of any software type. In this example, 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. In this example, 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.

In this example, 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)). In this example, 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. In another example, the representative items 18 can be "marked" with attributes that indicate whether certain events are to be passed to their corresponding subscribers. In one example, the representative items 18 may themselves be objects that "inherit" a communications function to reach a corresponding subscriber 15. For example, 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.

In this example, event distributor 10 also provides a ^"next indicator" 20. "Next indicator" 20 indicates a selected one of representative items 18 to be handled next. In one example implementation (e.g., C-÷). 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. In this example simplified process, 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).

More Detailed Example Representative Item and Event Insertion Processes

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.

In this more detailed example, the network user wishes to receive network state working/not working information. When the user process is created, so is 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).

In the case of this particular example, 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.

Now, if a network state change event appears, 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. In this example, let's assume that the creation of a new network user is itself an event, and that other network users need the new user's name and address. 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.

In this example, 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).

If, on the other hand, the event queue is empty ("^■yes^" exit to decision block 64). then 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.

In this example, 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). As discussed above, 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).

The processing defined by blocks 70. 72 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). 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.

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'. In this example, event distributor 10 distributes new event 14 to subscribers 15 based on representative items 18a. 18b, as described above. After distributing the event 14, 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'.

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

10, 10' may be useful, 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. For example, 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.

For example, when more routing capacity is needed, a new routing process can be dynamically created. 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. However, since 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.

In this particular example, suppose that router software processes of type A (corresponding to representative items 18a. 18b on the event distributor's item queue 16) are already in service. 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. Suppose now that 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. At this point, 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.

Once the newly created router process has been fully initialized and event distributor 10' has no more initialization (or other) events to distribute to it, 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.

In this more detailed example, 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. In more detail, 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). In this example, when a new router is inserted into the sub-event distributor item queue 16' (Figure 6A, blocks 100. 102). events within sub- phase one are distributed (Figure 6A. block 104), and 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).

Now suppose that 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).

Meanwhile, the router process sends an acknowledgment that it received the data properly (Figure 7, block 130). In this example, there is no acknowledgment on real events — only on sub-phases. 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). Eventually, the network process will acknowledge receipt of the sub-phase two data (block 130, Figure 7). In response to this further acknowledgment indicating that initialization of the subscriber is complete (Figure 7, decision blockl32 "yes" exit), the sub-event distributor 10' removes the representative item 18c from its item queue 16' and inserts it into the "run time handler" event distributor 10 item queue 16 (Figure7, block 136). This process step may also involve sending "start events" to the subscriber network process ~ or marking 'sub-phase = initiated" so the representative item knows what event distributor to talk to if needed. The router process is now in service.

While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

WHAT IS CLAIMED IS:

1. In an event distribution method for distributing events to subscribers, the event distribution method using an event queue that temporarily holds event notifications, an improvement comprising: storing, on a further queue, at least one representative item providing subscriber information, and distributing the event notifications to at least one subscriber based, at least in part, on said representative item.

2. An event distribution method as in claim 1 further including distributing events to plural subscribers of different types within a distributed, object oriented environment, and storing on said further queue a representative item corresponding to each of said plural subscribers.

3. An event distribution method as in claim 1 further including the step of distributing event notifications including an event type and an event attribute.

4. An event distribution method as in claim 1 wherein the storing step includes the step of storing, on the further queue, plural representative items each inheriting at least some behavioral characteristics.

5. An event distribution method as in claim 1 further including performing at least one function specified by the representative item to reach the subscriber.

6. An event distribution method as in claim 1 further including specifying, with the representative item, how to communicate with the subscriber.

7. An event distribution method as in claim 1 wherein the event distribution method includes a next indicator, and the method further includes accessing a selected representative item on the fuerther queue based on the next indicator.

8. An event distribution method as in claim 1 further including distributing the event to a sub-event distribution method.

9. In an event distributor for distributing events to subscribers, the event distributor including an event queue that temporarily holds event notifications, an improvement comprising: a further queue storing at least one representative item providing subscriber information, wherein the event distributor distributes the event notifications to at least one subscriber based, at least in part, on said representative item.

10. An event distributor as in claim 9 wherein the event distributor distributes events to plural subscribers of different types within a distributed, object oriented environment, and said further queue stores a representative item corresponding to each of said plural subscribers.

11. An event distributor as in claim 9 wherein the event notifications include an event type and an event attribute.

12. An event distributor as in claim 9 wherein the representative item queue stores plural representative items each inheriting at least some behavioral characteristics.

13. An event distributor as in claim 9 wherein the representative item includes at least one function to reach the subscriber.

14. An event distributor as in claim 9 wherein the representative item specifies how to communicate with the subscriber.

15. An event distributor as in claim 9 wherein the event distributor includes a next indicator, and accesses a selected representative item on the representative item queue based on the next indicator.

16. An event distributor as in claim 9 wherein the event distributor distributes the event to a sub-event distributor.

17. A distibuted event distribution arrangement including: a first event distributor including a first representative item queue holding representative items specifying information concerning event distribution to corresponding subscribers, and a second event distributor including a second representative item queue holding representative items specifying information concerning event distribution to corresponding subscribers, wherein the first event distributor distributes events to the second event distributor.

18. A distributed event distribution arrangement as in claim 17 further including means for moving at least one representative item between the first representative item queue and said second representative item queue.

19. A distributed event distribution arrangement as in claim 17 wherein each representative item includes a sub-phase indicator, and at least one of the first and second event distributors selectively distributes events based at least in part on the sub-phase indicator.

20. A distributed event distribution arrangement as in claim 17 wherein the first event distributor distributes events to in service subscribers, and the second event distributor distributes events to subscribers being initialized.

21. A method for initializing a router and placing it in service, the method comprising:

(a) creating a representative item corresponding to the router;

(b) placing the representative item on a queue of a first event distributor;

(c) distributing initialization events to the router via the first event distributor and the representative item;

(d) when the router is initialized, moving the representative item to a queue of a second event distributor; and (e) distributing run time events to the router via the second event distributor and the representative item.