ls given for the protocol that is to be integrated. 11.2.5.3 Handling Client Requests The question arises of what should be done in order to handle proprietary requests submitted by a client. CMS is equipped with an interface that defines and handles user-defined requests that are sent between a client and its server. A method speci- fies asynchronous requests and a different method sends asynchronous requests from the client to the server. 11 Configuration Management 11.2.5.4 Integrating Topology Modules The role of a topology module is to discover network resources and store them in a centralised database. Proprietary topology modules can be integrated with CM. This is sometimes necessary so that the system is aware of the devices present in the net- work so that devices can be configured from clients. A configuration client must list the devices present in the network so that the devices required can be selected from the client and a device list can be made from it, in order to allow a configuration task to be applied. The configuration client should be aware of the implementation so that it can search through the topology database and list the devices for configuration. Interaction with the topology data- base is made possible by a class that is provided for the purpose. 11.2.6 Security Implementation It is often not appropriate for any user to be able to make a change to network device configuration. A facility for user authentication is provided in precisely this vein. CMS is equipped with an API to allow the implementation of a custom authen- tication model. Even details such as the encryption mode for the username and password bytes can be customised. CMS uses an API to perform an authorization check for saving, deleting and exe- cuting tasks, saving and deleting device lists and saving and deleting data sources. An implementation must be provided for a checkPermission method in order to provide the necessary authorization checks. If the authorization fails, the method throws an exception. The ConfigPermi