The Concept and Design of the CMAB
The CMAB addresses the needs of storing and retrieving application configuration data by creating a simple, consistent, extensible interface, including:
- A flexible data model, allowing storage of simple name-value pairs or complex hierarchal data such as an XML fragment of user preference data. This flexible representation of configuration data is handled by the Configuration Section Handler or CSH interface.
- An ability to write to any data store via the Configuration Storage Provider or CSP interface. This gives you the ability to store data as an XML file in a database of your choice, or anything else you can think of.
- A mechanism to handle security and data integrity. Storing data, such as a connection string in an XML file, can at times be less than ideal. The Data Protection Provider, or DPP interface, provides mechanisms for signing the stored configuration data and encrypting it, helping to ensure that your data is not viewed or edited by unauthorized eyes.
- An option to cache the data stored by any CSP. With some CSP implementations, it can also refresh the cache when the data changes.
The CMAB provides pre-built implementations of the Configuration Section Handler (CSH), Configuration Storage Provider (CSP), and Data Protection Provider (DPP). You can use these as is, tweak them to meet your specific needs, or create your own implementation from scratch.
Using the CMAB
With the high extensibility of the CMAB, some up-front legwork must be done to insure a successful implementation. This is true for any new component you add to an existing or new application.
|The extensible design of the Configuration Management Application Block allows the creation of new components that plug right in.|
The first step is defining what the application is that you are building. During this design phase, you need to determine what application data should be configurable. A good rule of thumb is that any data that can be affected by the application's environmentsuch as network infrastructure, geographical location, external resources, and so forthshould be considered configurable data, and be stored in a central location.
The next step is to determine how to store the data. CMAB provides two mechanisms for storing configuration data, listed in Table 1.
Table 1: These Configuration Section Handlers (CSH) are included in CMAB.
CSH Class Implementations
Implements a class that takes a Hashtable and serializes it into XmlNode. It also takes serialized XML data and deserializes it back into a Hashtable. This is perfect for name value type data.
Implements a class that takes any class that supports the .NET XmlSerializer class and serializes it to an XmlNode. It also handles the deserialization back into its original class.
Once you have determined what data to store and how to store it, you must determine where to store it. Should the configuration data be stored in one central location or multiple locations? Should it be easily modifiable or should the data be encrypted? See Table 2 for the Data Storage Providers in CMAB.
Table 2:These Configuration Storage Providers (CMPs) are included in CMAB.
The SqlStorage provider allows configuration data to be stored in a SQL Server database. The data is stored as an XML document in a text field, making it difficult to update directly. It is suggested that all updates are made through the CMAB.
This implementation allows configuration data to be saved as an XML file that can be stored locally or on a network share.
Read-only data can also be stored directly in the .NET configuration file.
The RegistryStorage implementation allows data to be stored in the Windows registry. This has the same issues with direct editing as the SqlStorage implementation, and can only apply settings to applications hosted on the local computer.