Implement Configuration Service 5.0 without using template

Question

Can anyone point me to a resource that describes how to implement the Configuration Service 5.0 by manually adding it to an existing service structure?  I've downloaded and installed the Stock Trader Pro 5.0 and used the template to create a HelloWorld WCF service.  The solution structure created from the template, while partitioned correctly, is nothing like the solution structure generated by the WSSF template(s) which is what we are using.  It's not clear to me what is required by the Config Service and what is a result of creating an entire solution partitioned across tiers.

I'd like to know how to implement the Configuration Service with just the bits that allow shared central configuration for both on premise and off premise deployments.

[Edit]

A bit more specific question now that I've poored over the output of the visual studio template.  I can see that there are two projects that are key to implementing the Configuration service along with the config and node svc endpoints.  It seems the only way to create the configuration repository is to run the through the template.  If I have structured WCF services that I want to add Configuration support for, how can I create the repository for that service?  I can copy and modify the projects that are required over but not sure about the setup of the database (repository).  Any thoughts, help on this?

Thanks.

Tim

 

Answer 1

Sorry for delay.  I am working on a document for this.  A couple of notes on the process, however:

 

1.  You can use the wizard (recommended) to generate the database--the key elements as you note that need to get generated into the DB are the config and node service endpoints.  You will want to make sure you choose the correct host environment, becuase other generated artifacts/projects you will need will be generated according to the type of host environment you choose (IIS on-premises, NT Service on-premises, console app on-premises, windows app on-premises; or cloud Azure Web Role or cloud Azure worker role).  So this depends on your current host environment for your existing app/service.

2. There is also a stand-alone Repository create tool included in the Configuration VS Solution.  You can compile that and run it, it will generate the backing DB and code artifacts, but no solutions/vs projects (I recommend using the wizard above however, as you can just take the two required generated projects as is, and add to an existing solution).

3.  On the initial implementation, I suggest you just implement config service without adding any primary hosted services--just host your services as you normally do for now; you can decide later if you want any wcf services you are hosting to be managed also by the config service---they do not have to be (only node and config service need to be actually managed by config service).

4.  The repository DB is just referenced by a connection string in your web.config or app.config file---so once DB is created, this is how linked to from your existing app.

5.  You will need to manually edit/merge the generated app.config or web.config file into your own existing web/app.config file for your startup project.  This will be most tediuous step I think---you might want to start with the generated config file and just merge in your existing config sections that your app requires (or the other way around, it does not matter which you start from as the base). 

6.  There are two key generated projects from the Wizard that must be embedded into your existing solution, and appropriate references made for compilation.  These are the Settings project; and the HostConfigurationImplementation project.  As generated by the wizard, both will already have references to the shared libraries required by config service (\stocktrader\sharedlibraries\configuration directory).

7.  In addition, identify your startup project (for a web app this is the web app project itself with its global.asax and web.config files).  If a Web app or Azure Web Role, you will need to merge the generated global.asax file (pretty simple) into any existing global.asx for proper app bootstrapping/stopping at startup (along with merging web.config as generated with your existing web.config as in step 5).  If another type of on-premises app; you will need to look at the app startup logic included in the wizard-generated startup project, and simply include this logic in your existing app startup project/logic (for example, for an NT Service or console app).  You want to merge in everything generated, and this will also require adding correct shared library references based on the generated C# using statements.  If this is either a Azure web role or worker role, please also include the generated startup cmd scripts that are important.  For Azure, these are in the roleentry generated project+files (and global.asax if a web role).

So, in a nutshell, for a base implementation of just config service for managing db-stored config settings, active nodes, etc; these are the required steps.  You can decide later if you want config service to also manage any WCF services you have--this is not a requirements for a base implementation. 

 

---

Greg Leake, Microsoft

Answer 2

Hi Greg,

              I am new to this configuration service. I am also trying to take apart config modules and use them with my wcf services to manage config details. I have 3 kinds of wcf services (business, data, entity) and each kind has 6/7 specific wcf services (accounts, report, inventory etc...). So in total I will be having 20/25 wcf services.

What I need

1. Need to maintain common config details for each kind (business services, data services and entity services)

2. Need to maintain each and every wcf service's config details.

3. All of the services will be hosted in different different environments.

4. Load balancing is not important now

Based on that, I want to extract config service separately into one library, node service separately into another library and attach these with my web services. And create a link between these config services based on the type of services they are serving and create a master config service for each kind and maintain common config details through that.

I am still exploring configuration service source code. It would be of great help if you show me the direction. 

Thanks.

 

Answer 3

Sorry this post got a bit buried in some random posts non-stocktrader related.

The design is such that each "host" gets its own autonomous config repository.  By "host" I mean the physical host app such as IIS Web app, console app, NT Service, Azure Worker Role, Azure Web Role, etc.  As you know with WCF a "host" can host mulitple services; including mulitple service hosts within one host process.

So with current design (which was done to keep services completely autonomous from each other); two different "host" processes cannot share a common config DB.  So it might be more of a challenge to do what I think you want to do without custom coding (modifying existing config service or implementing a service that perhaps just doles out config information to other hosts as requested).

For a single "host", which might be hosting multiple services/service URis, you can create custom config groups; config settings are just variables that get populated on startup via reflection from config DB; you can override behavior and for example use custom classes with their own serialization if some config is beyond just basic .NET types (string, int, float, etc).  "hosts" can be any type of environment such as IIS app, console or exe app including win app, NT Service, Azure Web/Worker Role---anything can host WCF services, and config service likewise can be hosted in any environment--you choose in the VS Wizard when generating a stub service.

Load balancing client is a special client class you inherit from (you can generate this client using Repository Create Tool--Client Generation Tab).  But, completely optional since any service you host can also simply be accessed via std WCF practice/std WCF client.  Load balancing is meant for on-premise (vs. Azure) installs such as in mulitple potentially virtual machines where there is no hardware load balancer.  Again--optional.  On Azure of course load balancing is always automatic, but config service does require simple config checkbox to let it know services will be automatically load balanced (and you would do the same if using on-premise hardware load balancer).

---

Greg Leake, Microsoft

Answer 4

also I should add to response above:

There are two classes of config info stored/used by config services:

a) Custom config settings you use however you want, loaded automatically from DB and auto-bound via reflection to specific config settings variables you setup.  Access is fast--since these are local in-memory variable just like anything you would throw into <appsettings> section of a app.config or web.config file.  Config + Node Service keep these in-sync across mulitple nodes, and do all loading for you from DB of the values.  You initially setup these settings via ConfigWeb UI and creating the variables in the settings.cs class vs. putting into a config file.  Using eitehr ConfigWeb or a Config Service API call, updates to these values are real-time without app downtime, synced across all nodes (load balanced nodes) running--and of course persisted as well into config DB (SQL Server/SQL Azure).

b) WCF Service config details.  If you want to use this feature for your custom services, you can, but is optional.  You can manually construct your services ala std WCF programming and/or in combo with std way to set these up using web.config/app.config practices for WCF.  The custom services you host are called "Primary Services" in Config Service terms--and you do not have to use Config Service to set these up--you can do yourself in which case Config Service does not even need to know about them.  The advantage of using Config Service to set these up is a more point-click interface (ConfigWeb) to setup bindings, service hosts automatically spawned, etc without manual WCF coding.  But, if limiting (not all bindings supported but most are, for example), you do not have to go through Config Service to manage your custom services--just implement config service but construct your own WCF hosts, servicehostfactories and the like.  You can still use config service to keep your custom config settings in sync across nodes, and manage centrally from DB vs. web.config/app.config files.

When implementing config services (you should start with VS Wizard included to generate base implementation which you then modify), Node and Cnfig Service hosts are automatically constructed.  These services are infrastructure required services that keep the settings repository up to date, allow real-time updates of settings across load balanced nodes, etc.

---

Greg Leake, Microsoft