valuable step forward. The environ- ment proposed includes services for monitoring and asynchronous event handling. The dynamic characteristics of this environment allow the administrator to extend or modify functionality without stopping the system, and also allow the administrator to redefine dynamically the servers supporting the network management application. Traditionally, network management applications consume a great deal of pro- cessing resources. As institutional networks grow in size, the conventional network management architecture, in which a centralised management application is respon- sible for monitoring and handling events of the entire network, ceases to be feasible. On the other hand, most computer networks present high percentages of idle proces- sor time. Therefore, it is natural to distribute the workload associated with network management among available machines. Even if dedicated servers carry out net- work management, distribution means that new servers can be added as needed, instead of replacing a server with a more powerful machine every time it reaches its limit. This distributed approach has been analysed in several publications. Once we decide to decentralise the management application, creating a distrib- uted application with processes running on several machines, we must decide what communication infrastructure will be used. Traditional management protocols are too low-level and designed for communication with network devices. A higher level communication model allows us to abstract from specific protocols and to integrate management of devices with other requirements, such as management of network services. Distributed components models have gained maturity in recent years. Among these models, CORBA is a de facto standard and deals well with heterogeneity and interoperability. It therefore seems natural to use CORBA's infrastructure as a basis for a distributed management application. However, the traditional use of CORBA, using only static language bindings, usually C+ + or 