Enterprise WCF - Integrate WCF Configuration into Your Enterprise Framework

Background

Lots of people declares they are using WCF in their “enterprise” distributed software development together with other SOA technologies, and even calls their software architecture WCF based. If you are one of them, could you please answer the questions below; or, if you plan to be one of them, ask yourself the questions below:

• How many WCF services are their in your enterprise architecture?
• How many sub-systems and databases?
• How many servers deploying or consuming WCF services?
• How many load-balanced server farms and application tiers related to WCF?
• How many deployment server environments (DEV, QA, Staging, Production, etc)?
• Are your servers and farms in different domains, with different connectivity and different network bandwidth?
• What are your auto-build, test and release processes for WCF services?
• How do you deal with the WCF service configuration difference for different deployment server environments?
• How often are your WCF service configuration changed?
• How do you maintain your WCF service configuration changes?
• Where are your WCF service configuration saved?

The goal to ask the questions above is to lead you thinking & agree:

• The management of WCF services in enterprise distributed software development is not an easy stuff.
• To put WCF service configuration in your application configuration files is a nightmare for enterprise distributed software development.
• For enterprise distributed software development involving WCF service, an “enterprise framework” integrating consistent centralized WCF service configuration management is highly necessary.

Let me give a definition for “enterprise framework” discussed in this text: a set of shared software development components, and related configuration persistence and development & management process for all the distributed application development in enterprise.

Give you an example of “enterprise framework” in my company, even before using WCF, we already have a set of shared software components (VJ++/VB/DotNet COM DLLs for Non-DotNet applications; and DotNet DLLs for all DotNet applications), and a centralized database based configuration store for all the application app settings, connection strings, Web Service URLs and dependency injected object factory. We also have related development, maintain and release process for both the software components and the data in the configuration store.

Since you agree (I assumes) about the “the goal to ask the questions” above, when beginning to widely use WCF in our enterprise application development, you could imagine, we try to integrate WCF service configuration into our enterprise framework.

Articles I posted before already shows the possibility to centralize and programmatically configure all WCF service configuration. The rest of this text will introduce the summary of how we integrate WCF service configuration into our enterprise framework, and show you how to easily integrate WCF service configuration into other frameworks on the top of NIntegrate – an open source DotNet integration framework.

How We Integrate WCF Configuration into Our Enterprise Framework

I don’t want to expose any confidential information of my company, the purpose of this chapter is only to show you the benefits we get from the solution and give you more confidence to adopt a similar solution.

• Since we put all the configuration for applications in centralized database even before using WCF, the most suitable place to save all WCF configuration is the same database. And because our existing configuration are grouped by servers, load-balanced server farms and different applications, when extending the database to support WCF configuration, we easily get the ability to reuse WCF configuration at application, server or even farm scope for contracts, addresses, bindings, behaviors, security, etc.
• Since we put all the configuration in database instead of application configuration files, our applications could have very light application configuration files, and even no application files. This makes the auto-build & deployment of our application on different deployment server environment be super easy - no code change required for release packages on different server environments.
• To read configuration from database for publishing & consuming WCF services, we created some shared components (DotNet components only) to our development framework library, including custom ServiceHost Factory for hosting services and custom ChannelFactory for consuming services. For non-DotNet applications, they could also consume WCF services through Web Service binding or through DotNet COM wrappers (for windows apps only).
• The shared components not only read & cache WCF configuration from database, but also automatically refresh the cache in memory through background threads according to specified refresh policy, so it is easy to change WCF configuration at runtime, ex., disable/enable services or endpoints, change bindings, addresses or other settings, apply consistent health monitor, performance trace, error handling & logging, etc, through custom behaviors or other extension APIs of WCF.

Integrate WCF Configuration into a Dummy Enterprise Framework on the Top of NIntegrate

To demonstrate how to integrate WCF configuration into an enterprise framework, I’ll introduce a dummy enterprise framework in this chapter.

The attached picture is the class diagram of dummy enterprise framework integrated with NIntegrate:

Before integrated with NIntegrate, all the classes and methods containing the word ‘Wcf’ does not exist. The Dummy framework provides abilities to create class instances dependency injected, and get application variables & connection strings centrally, which are very common functions an enterprise framework may provide.

To use the DummyFramework, easily call DummyFrameworkConfigurationManager.GetConfiguration() to get an instance of DummyFrameworkConfiguration, and use it to construct a DummyFramework instance. Then you can call methods on DummyFramework.

On the top of NIntegrate, we could easily give the WCF configuration & custom persistence ability to the dummy framework.

To consume a WCF service, call the CreateWcfChannel<T>() method on DummyFramework, inside which reads WCF client endpoint configuration from DummyFrameworkConfiguration, which internally could load the configuration from anywhere rather than only in application configuration file (The returning instance is WcfClientEndpoint class, which is a serializable WCF DataContract defined in NIntegrate). The CreateWcfChannel<T>() method calls WcfChannelFactoryFactory.CreateChannelFactory<TChannel>() method, which is defined in NIntegrate, creates the ChannelFactory, cache it and returns an instance of WcfChannelWrapper class (also defined in NIntegrate), which implements the best practice for disposing a WCF channel instance.

Sample code as below:

    var df = new DummyFramework(DummyFrameworkConfiguationManager.GetConfiguration());
    using (var wrapper = df.CreateWcfChannel<IDummyService>())
    {
        Response.Write(wrapper.Channel.SayHello());
    }

To publish a WcfService, create the DummyWcfServiceHostFactory class, and set the Factory property of a .svc file as below:

<%@ ServiceHost Service="DummyEnterpriseService.Implementation.DummyService"
    Factory="DummyEnterpriseFramework.DummyWcfServiceHostFactory" %>

The DummyWcfServiceHostFactory class inherits the WcfServiceHostFactory class defined in NIntegrate, and overrides the LoadServiceConfiguration() method to load configuration from anywhere expected (The returning instance is WcfService class, which is a serializable Wcf DataContract defined in NIntegrate).

Attached the source code of the sample DummyEnterpriseFrameworkIntegration:

DummyEnterpriseFrameworkIntegration.zip

 

Original by Teddy's Knowledge Base, All rights reserved.

First Publish: http://www.cnblogs.com/teddyma/archive/2009/08/28/1556076.html

 

//The end