ceive an event. This method receives events in a standard event format, which conforms to the ITU X.733 recom- mendation. Event agents may also receive SNMP traps. An event agent can deliver filtered or generated events either to an event dis- patcher or to another event agent. Several event agents can be linked forming a hierarchy similar to a tree, in which each level receives and correlates events gener- ated by inferior levels (see Figure 14.2). As a result, the load of processing events OSS for Telecom Networks may be distributed over event agents in different servers. The structure of this tree can be dynamically redefined; the CORBA configuration method at each agent can be used to redefine the agent to which it should send its events. WebComm event agents are started manually or at machine boot. They then remain idle until receiving a configuration through their CORBA interface. The Event Dispatcher is the process responsible for delivering events to client applications. It is also responsible for storing the events in a database, which can be anything from a relational database to a simple file. In WebComm, the asynchron- ous reception of events is made possible through the use of Java applets. Applets are used by users who are distributed throughout the network and allow the server to communicate asynchronously with a client, thus escaping the client-server para- digm imposed by the web. The event dispatcher can be regarded as a specialised event agent for distributing events to clients. It also receives events through its CORBA interface. This interface is identical with the event agent interface with an additional method which allows the caller to retrieve the TCP port at which the event dis- patcher is awaiting clients' connections. This method is necessary for applets to know where the event dispatcher is awaiting connections, since applets communi- cate with the event dispatcher using TCP sockets. When the event dispatcher is started, it waits for client TCP connections. Because of security restric