In this post I will explain at high level the concept of policy based configuration and I will be providing a POC.
Anyone that has ever worked with WCF in a proper scaled application with many many micro services must know about the pain of maintaining the configuration files, I am now not only referring to maintenance of the client addresses but also to the service behaviours, binding configurations and extension behaviours.
After months of seeking an alternative way of maintaining the configuration files I was introduced to the concept of policy based configuration by Monty from IDesign and I set out to develop this POC.
What is a policy?
Although configuration is often considered to be part of the deployment considerations there are some of it that is really an architecture consideration decided upon by the System Architect.
These configurations should not be changeable at deployment time. Things like the binding, operation behaviour, security, validation, transaction, reader quotas, instance context mode and concurrency mode all form part of the decisions that need to be made upfront by the architect. All these decision can be brought together under the concept of a policy.
A policy is actually a service behaviour that one codes and applies to a service at time of implementation. This policy will enforce / apply the default configuration to a service and proxy as dictated by the designed architecture.
As can be seen in the image above. A policy controls how your service is hosted and the behaviours that goes along with it. The beauty of this is that if a service is being hosted using the default configuration as decided upon when it was designed, no configuration files will be required.
Requires a framework
A policy consist out of 2 attribute classes, one that gets applied to the client proxy and one that gets applied to the service. They work together to dictate how a service is hosted and how a client needs to go about to speak to the service. This works beautifully when you are in control of both sides of the wire, the client and the service. When you are only in control of one of the sides you can still write a policy for your own side.
The policy attribute can do 80% of the work as it is being loaded but unfortunately a small framework is required. The framework needs to find the policy attribute type defined on the proxy or service and call either create channel or create host which then takes care of the rest. The framework for building your own policy based configuration can be downloaded here. The framework provided is a sample, please treat it as such.
There are some restrictions to using a policy based configuration, especially if the policy has to dictate the addresses.
- 1 Policy can only implement 1 binding.
- 1 Service can only implement 1 contract.
This is a limitation due to being able to calculate a unique address to the service from the client. - No contracts can be reused.
This is a limitation due to being able to calculate a unique address to the service from the client.
The downloadable framework.
The framework solution contains several projects that work together to provide you with a infrastructure framework that will allow you to easily apply policies to your services and proxies.
The Host project, will automatically at runtime find services within its bin directory and host it. This allows for easy deployment as it comes down to simply copying files from one location to another to spin up a new host.
Applying the policies
The service
As can be seen in the image below a policy gets applied to the service class by simply adding the policy attribute above it. This “intranet policy” as an example will enforce net.tcp endpoints with security on this service.
But what if you have a service that does not fit 100% in with the policy? What I you maybe need to set a specific time out?
The policy can provide overrides. This will allow the developer to specify at design time that this service has slightly different requirements and seeing as these requirements are architectural decisions there is nothing wrong with hard coding these requirements as they should never change.
Any number of overrides can be provided. The person that codes the policy just need to make provision for these overrides.
The proxy
Apply the policy to the proxy is no different from applying it to the service. In the example below I apply the policy to the proxy. Now the proxy will know to use a net.tcp binding to connect to the serivce. It will also know what the service address is because the policy by default calculates and assigns the address.
It is important for the service and proxy to have the same configuration. So the policy needs to provide the same overrides for the proxy as what the service policy had.
I have given a high level explanation of policy based configuration. I hope that it was helpful enough to help some with similar problem.s I have applied and used this concept at work with great success so far.