Using Policy Injection and Attributes to preempt calls to non-functioning systems

It’s a waste of processor cycles and user time to make web service calls to systems that are not currently functioning. I was involved in building a solution that allows code that depends on non-functioning systems to be skipped entirely. Code simply needs to be attributed with the systems it uses. Then a policy injection handler will throw an exception without even calling that code if a system is known to be unavailable.

I document the parts of the system I built in this article. The moving parts of involved in this solution are:

Agents. The agents are the classes that make web service calls to external systems.

FunctionalArea attributes. Agent interfaces are marked up with these attributes to indicate dependencies on external systems.

FunctionalAreaUnavailableException – thrown to indicate an agent method call has been made involving an unavailable system.

SystemStatusAgent. This service keeps track of the unavailability of systems, by receiving information from the application when a FunctionalAreaUnavailableException is thrown, and through its own monitoring. I don’t document it in this blog post.

The InterceptorBehavior. Policy injection causes this to be ran before each agent method call. It throws a FunctionalAreaUnavailableException when an attributed agent has a web service exception, or instead of a method call involving a system the SystemStatusAgent considers unavailable.

Global exception handling. Catches FunctionalAreaUnavailableExceptions, notifies the SystemStatusAgent of them, and shows the user an error indicating the system they are trying to work with is currently unavailable. I don’t document it in this blog post.

I was able to policy inject all Agents as they were constructed in our AgentFactory. I wished to use configuration based injection. But (if my memory serves me right) with Unity 2.0policy injection, you can’t use configuration to generated an injected object that is of a concrete type. I had to specify interception behaviours (Unity synonym for policy handler) in code to use the required interceptor, TransparentProxyInterceptor.

I utilised this in our AgentFactory as this simplified and abbreviated code shows. The PolicyInjectionHelper means that whilst the interception behaviours couldn’t be specified in config, they are easy to see in code (RequiresFunctionalAreaPolicyHandler below).

Policy Injection has its costs. Apart from the additional complexity that policy injection introduces to your code, the usage of the proxy class introduces some overhead to every usage of a policy injected object. And you should be sure that a requirement is a cross cutting concern – do some reading about Aspect-oriented programming for some ideas about how policy injection should be used.

System availability is a cross-cutting concern for agents, which are defined as the set of classes that provide access to external systems in the application I’m dealing with. And the cost of accessing agents through a proxy is fractional compared to the cost of the actual web service calls involved.

This work resulted in a better user user experience when systems are down by providing fast failure, rather than making users wait for timeouts known to be inevitable. The SystemStatusAgent also provides monitoring of the health of the systems the application depends on. I found Unity policy injection wasn’t entirely intuitive. But I’m pleased with the outcome.