inventory and network inputs are collected. Pre-provisioning filters are applied just before the network configuration actions begin. 3. Post-provisioning filters are invoked once network configuration is complete. These filters are in separate configuration files, where the template name and complete class names are specified. In all cases, the template with the current con- figuration data is supplied to the filter and the returned value is used for the next stage of processing. Filters can be used to gather additional network and inventory data from any appropriate source. This allows complete extensibility for specific needs that are not met by the provisioning flow described earlier. 6.9.7 Application-specific Extension Modules The ability to implement domain and vendor-specific extensions is an important feature for many service providers. This is accomplished by allowing OEMs to develop API extensions that leverage the provisioning APIs, the configuration mod- ule APIs and the topology module APIs. The design of application extensibility is illustrated in Figure 6.8. One or more domain and application extensions can be added to the provisioning module, via an XML configuration file. Based on this configuration file, the application extensions OSS for Telecom Networks Provisioning Module CORBA, RMI or XML Provisioning API CORBA, RMI Extension API Core Functions or XML Custom Extensions Remote MO Extensions Provisioning Provisioning Templates Rules Application Extension Fault Network Configuration Module Management Inventory Figure 6.8 Application extension design. will be initialised and made available. Each module is named and specific exten- sions can be accessed by name from the main provisioning API or from any of its extensions. In addition to providing new API functions to provisioning clients, extensions can work with templates and extend the template processing capabilities in three ways: Extensions can support special processing of template data as part of every client interaction: initializing and