The last post provided the introduction about what “policy” in the context of WCF is about. Now we are going to go ahead and actually build our own policy.
Note: This post is part of a series. The TOC can be found here…
Defining the policy
For this endeavor we keep the actual functionality simple: During a service call, client and server are to add timestamps whenever a message goes out or comes in. Those timestamps shall be maintained in a list that is forwarded with each message, doing so as SOAP header, since this is not part of the regular contracts. This will create a trace of the whole request/response chain. (“Chain” may sound a little presumptuous, but if one service calls others, this might become more of a challenge.) We’ll call this (a little snobbish) “tracking policy”.
Configuring the policy
The first step of the implementation is relatively unspectacular. Since we want to influence the behavior of the service, we need some kind of WCF behavior. I chose a service behavior, other demands may call for a different behavior type. The canonical implementation for a respective attribute looks like this…
… with all the method bodies empty. This is sufficient to be put on a service:
For details on behaviors (including extension elements to be used in configuration rather than code) see here.
Publishing the policy
Now for the first interesting part: How do we insert a policy assertion for our policy into the WSDL? WCF supports writing policy assertions via IPolicyExportExtension, however only for binding elements, not for behaviors. Of course we could provide a respective binding element and ask the developer to configure it – on top of the behavior that he already put on his service. Not exactly comfortable and a source of errors.
There is an alternative, though: Our behavior can add the binding element during the IServiceBehavior.Validate call, as shown here:
(This depends on the employment of a custom binding. I will address the question of other bindings in a later post.)
Now, IServiceBehavior.Validate is obviously not intended for this kind of manipulations, but what the heck, it works, and it makes things easier for the application developer.
Whenever the WSDL is generated, the binding elements implementing IPolicyExportExtension will be asked to insert their policy assertion. IPolicyExportExtension.ExportPolicy will be called and the parameter of type PolicyConversionContext provides the plumbing we need. The policy assertion itself is nothing more than an arbitrary XML fragment – the identifying part is an XML element – which we can create on the fly:
With this code in place, the WSDL should include the XML we just generated. Perhaps in combination with other policy assertions, depending on how the service is configured, but similar to this:
In our case we only needed the existence of the XML element to publish the policy. More complex policies may need to publish additional information. In this case all you need to do is to include XML attributes and/or elements as you like as children of the root element of the policy assertion. WS-Security Policy goes even further and provides several different policy assertions.
That concludes the server perspective for our policy assertion. The next post will look at it from the client perspective.
That’s all for now folks,