AJ's blog

March 28, 2015

WCF Policy – Part 11: Famous Last Words

Our policy works. Every aspect – defining the standard, switching it on, publishing the policy assertion, evaluating it for the client proxy, default behavior, and making the information accessible on client and server – contributes to a system where all pieces work together.

To get an overview and TOC, please refer to the initial post

The policy plays well with WCF. The application developer can switch the policy on, and everything else happens automatically (with minor exceptions, e.g. registering the policy importer). If needs be he can access the information similar to other built in information (again, with minor exceptions). This is very close to what’s provided by WCF out of the box.

And what’s more, it builds on standards that are not platform dependent: WSDL, WS-Policy, SOAP. Other platforms offer similar capabilities, for example Metro for the Java world. (This work is actually based on project where cross platform availability was demanded.)


On the other hand, we had to do quite a lot to make it work. Question is, when and why would you want to do this?

Having a WCF Policy is certainly nice. Building a WCF Policy however is something that needs to be decided carefully.

Creating policies is certainly not part of the every-day-work of the average developer. Rather it’s part of the foundation laid out by experienced developers or some framework team in the organization. Policies are also usually cross cutting concerns, orthogonal to the business demands, and perhaps optional. And finally the effort is only justifiable for demands occurring regularly.

The biggest obstacle in my opinion is that implementing a WCF Policy requires a familiarity with the internal workings of the WCF that goes beyond what the average developer – including service developers – need and usually have. On the other hand, should you have someone with that skill, then policies might be a means to provide complex demands to other application developers in a seamless and easy-to-use way, and shield them from WCF intricacies.

In other words: Custom WCF Policies may be a rare demand. But at times, and if circumstances allow, they can be very handy.


Did I forget something? Oh, yes. You can find the sample application on github

That’s all for now folks,

March 15, 2015

WCF Policy – Part 10: Addendum: Extending Bindings

Filed under: .NET, .NET Framework, C#, SOA, Software Architecture, Software Development, WCF — ajdotnet @ 4:38 pm

During the last posts we talked a lot about behaviors, but only in passing about bindings.


Bindings for policies relying on behaviors.

Our policy was defined in a way that extended the behavior of clients and services. Still we needed a BindingElement for exporting the policy assertion (and we took a shortcut on top of that). However, in order to use BindingElements you need a custom binding (no WsHttpBinding or other). Should you have another binding already in place, you need to change this – which however implies an unnecessarily complicated translation from other bindings to custom bindings. Yaron’s converter might help with this.


Policies relying on bindings.

Some demands do not affect the behavior of the service, but the message content on the wire. Examples include custom encodings, compression, or similar requirements. These demands should be realized by bindings instead of behaviors. Unfortunately this requires quite a bit more effort.

Providing a custom binding implementing the demand is probably the simple part. On top of that, one needs to customize the building of the channel. Replacing an existing binding, e.g. the message encoding stage, is shown in WCF Extensibility – Policy Import / Export Extensions. It gets even more complicated if an additional binding needs to be inserted. The SDK sample Custom Message Interceptor shows how this can be accomplished. Carlos explains it a bit more in detail in his posts WCF Extensibility – Channels and WCF Extensibility – Channels (server side).


As a personal note…

I cannot see any reason why the above tasks have to be so complicated or why they require so much effort. Specialized bindings, such as WsHttpBinding build internally on binding elements, so there should be a straight forward translation between bindings. Similarly WCF channels are a simple pipeline, which is a pattern that is common enough. Why are the stages nearly set in stone, why does it take so much effort to introduce extensions?

WCF is at times rather complex due to the complexity of the protocols that need to be configured. Adding unnecessarily (I think) to this complexity is just annoying.

Just my 0,02€.


That’s all for now folks,

Blog at WordPress.com.