Distributed .NET Cloud-based Configuration Client.

 

---

Diagram depicts a configurator writing configuration data to a central cloud-based storage. Applications can have seperate configuration data, or shared configuration data.

---

Concept

As cloud-based SaaS, PaaS and IaaS systems gain more traction in the enterprise, some desirable but previously difficult-to-achieve enterprise-scale concepts are coming within reach.

One such concept is the Distributed Application Configuration Server (a single repository for all application configuration data, for all applications, across the enterprise) 

 

D.C3 is designed to be the client in a cloud-based Distributed Application Configuration System. The D.C3 system uses Azure Storage as the repository for the configuration data.

If you are new to Azure or Azure Storage, visit this microsoft link to learn more.

 

To create a functional, single repository for all application configuration data in an enterprise, we need at least 4 capabilities

CAP.1 can be realized with any Azure Blob Storage GUI client. It is recommended that you use a GUI client that presents a hierarchical folder view of the storage container. We recommend Azure Explorer

CAP.2 can be realized with the D.C3 client, which is the focus of this article.

CAP.3 can be realized by using the app.config or web.config in conjunction with D.C3. We need CAP.3 to ensure that Azure Storage doesn't become a stumbling block in the Dev. Environment.

CAP.4 can be realized with Azure Blob Storage. Azure Storage has built-in redundancy and availability features. 

 

---

Usage

To use a central repository for your configuration, you need to:

 

Create a serializable class

For RQ.1, just create a POCO class (from the sample files download, see SampleConfiguration.cs_, sample.config.Json and sample.config.xml). D.C3 has built-in support for Xml and Json serialization. If you require special capabilities, inherit the JsonSerializationServiceProvider or the XmlSerializationServiceProvider class and override the appropriate methods (read more about this in the "Overriding Default Behavior" section.)

 

Upload the serialized Configuration Object (RQ.2)

To help organize the configuration data, and to allow for short connection strings, D.C3 uses a convention-based system for tracking the configuration objects for the various applications.

There are 2 types hierarchies available.

1) Hierarchy with no environment qualifier: [Container]/[Sub-Folder]/[Application Name]/[File Name]

2) Hierarchy with environment qualifier: [Container]/[Environment]/[Sub-Folder]/[Application Name]/[File Name]

Container: Container Name (Optional. Default is: "acserver". This container should be used exclusively by the configuration server)

Sub-Folder: Sub-Folder Path (Optional. Default is: "apps")

Application Name: The name of the application (Required)

File Name: The name of the file that contains the serialized object: (Optional. Default is: "config.xml")

Environment Name: (Optional. None default is assigned. If the environment name is absent, it will be omitted from the path)

Above is a screenshot of the Azure Explorer. The bottom left of the image shows the hierarchy with no environment qualifier.

 

Above is a screenshot of the Azure Explorer. The bottom left of the image shows the hierarchy with an environment qualifier ("e.dev")

 

Make use of config object in application code (RQ3):

Once your environment is correctly setup, and the serialized configuration object have been uploaded to Azure Storage, accessing your configuration object is a snip. 

Example 1, using the AppConfigurationProvider class based on settings on the config file.

var configObject = (new AppConfigurationProvider()).Get<SampleConfiguration>();

 

Example 2, using the AppConfigurationProvider class with an instance of a ConnectionSettings class:

var configObject = (new AppConfigurationProvider(conSettings)).Get<Types.SampleConfiguration>();

Note: the full name for the provider is TECHIS.Cloud.Configuration.AppConfigurationProvider

 

 

---

 

Connection Strings

Azure Storage Connection String

To gain read access to the storage account, use either a Storage Account connection string that is based on the account name and key, or a Blob Container Uri that is based on a Sas token. See below

<add key="StorageConnectionString" value="DefaultEndpointsProtocol=https;AccountName=portalvhdsqwee;AccountKey=3324fgsddsfder23gmg"/>

<add key="AppConfigContainerSasUri" value="https://[account name].blob.core.windows.net:443/container?[parameters]"/>

 

 

Configuration Server Connection String

D.C3's behavior is configured via the connection string. The minimal connection string will assume the default values for ContainerName, Sub-Folder, and FileName. In addition, the minimal connection string also assumes that there's no environment qualifier.

<add key="AppConfigServerConnectionString" value="ApplicationName=sales.analytics"/>

OR

<add key="AppConfigServerConnectionString" value="sales.analytics"/>

Other examples

<add key="AppConfigServerConnectionString" value="ApplicationName=sales.analytics;FileName=config.json"/>

Shows connection string with ApplicationName and FileName specified

 

<add key="AppConfigServerConnectionString" value="ApplicationName=sales.analytics;EnvironmentName=e.dev"/>

Shows connection string with ApplicationName and EnvironmentName specified.

 

<add key="AppConfigServerConnectionString" value="ApplicationName=sales.analytics;ContainerName=acserver; EnvironmentName=e.dev;FileName=config.json;SubFolder=apps;"/>

Shows connection string with all attributes assigned (except the "Disabled" attribute)

 

<add key="AppConfigServerConnectionString" value="ApplicationName=sales.analytics;FileName=config.json;Disabled=true"/>

Shows connection string with the Disabled attribute assigned.

 

---

 

Storing Your Config Object in the config file

D.C3 includes a configuration section handler as well as a configuration object reader.

At design-time and while you are still developing your application, you may prefer to store your configuration object in your config file.

The config sample below shows your how to do that. you have the option of using Xml (via the "SerializedObject" element,) or Json (via the SerializedJson element). See the Sample.Local.Config.Xml file for a clear example.

 

<Info>

<SerializedJson DataType="TECHIS.Cloud.Configuration.Test.Types.SampleConfiguration, TECHIS.Cloud.Configuration.Test">

<![CDATA[{

"Path":"http://techinceptions.com/DC3",

"Name":"Test",

"Description":"Description is ...",

"GlobalId":"A1D6E6A6-04D7-4b5c-8334-A9FBF6A0BEFD"

}]]>

</SerializedJson>

</Info>

Storing Config Object as Json in config file.

 

<Info>

<SerializedObject DataType="TECHIS.Cloud.Configuration.Test.Types.SampleConfiguration, TECHIS.Cloud.Configuration.Test">

<SampleConfiguration>

<Path>http://techinceptions.com/DC3</Path>

<Name>Test</Name>

<Description>Description is ...</Description>

<GlobalId>{A1D6E6A6-04D7-4b5c-8334-A9FBF6A0BEFD}</GlobalId>

</SampleConfiguration>

</SerializedObject>

</Info>

 Storing Config Object as Xml in config file

 

Overriding Default Behavior

Internally, D.C3 uses the Unity IoC Container and the primary capabilities of D.C3 are expressed using a provider model.

The following provider classes may be inherited from and relevant methods overridden to change the behavior of D.C3

A sample configuration file with Unity configuration is included (See Sample.Unity.Config.xml)

It is also required to add the following setting to appsettings

<add key="AppConfigServerLoadIoCContainer" value="true"/>

 

Next steps

Use the "Getting Started" links to install the D.C3 package, download a free Azure Storage Explorer, get the sample files and also get a free C# test project for D.C3