Migrating from ‘asmx’ webservices to WCF with Spring.Net

Building webservices with Spring.Net is a piece of cake. The framework supported a single programming model long before WCF was available, exposing your service was just a different entry in your configuration. If you’re interested how you need to do this, please read my previous blog entries.

WCF introduced this same concepts to the main .Net Framework but also provides a lot of other functionality out of the box. Security, logging, … just change some xml tag and you’re done.

I make it sound a bit too easy here 🙂 figuring out what is wrong in your service section of the app/web.config is frustrating even with all the tools that are available.

So what do we need to change in our application to switch from ‘old’ webservices to the WCF counterpart?

Well if you’ve been following some best practices then your service is already behind an interface, and that means the only thing you have to change is the way Spring injects this service in your application.

public class OrderPresenter
	: IOrderPresenter
	public IOrderService OrderService { get; set; }
	public IOrderView View { get; set; }

With the code example above the presenter expects an instance which implements the IOrderService interface, it doesn’t care if it’s WCF, ‘asmx’ webservice or just a local object.

To add a WCF client object you do not need to change anything in your existing codebase, only the way Spring can find the Service you’re connecting to as illustrated below.

<object id="OrderService" type="ServiceContract.IOrderService, ServiceContract"
		factory-method="CreateChannel" />
<object id="OrderServiceChannelFactory"
	type="System.ServiceModel.ChannelFactory&lt;ServiceContract.IOrderService>, System.ServiceModel">
	<constructor-arg name="endpointConfigurationName" value="OrderServiceEndpoint" />

The OrderService above will be used by my presenter, and is created via the OrderServiceChannelFactory. Anyone who has some experience with WCF sees that this is just the same as you would do in code when using channels.

So we’re done!

No, not really. There is one, rather big, caveat.

In the ‘old’ days my client service reference would still function if there had been an exception. For example if the network cable was unplugged and I called a method on the server I’d get an exception. If I’d plug the cable back in and call the method again, my client service reference would still function and call the server successfully.

This is not the case with WCF channels, if there is an exception, either communication wise, like the unplugged network cable, or the server throws an exception my client channel will transition in a ‘faulted’ state. Any calls I make on this instance will fail, I need a new instance from the channelfactory to get my application going again.

I could change my presenter to check the service reference, but that would mean I need to couple my presenter to WCF and need to add new behaviour. This is not something you’d want to do. I can’t get around this problem by ‘normal’ AOP techniques. I can’t let the channel check it’s own status and have it magically change it’s own memory reference to a new instance.

Wouldn’t it be great if that boilerplate code (checking the state, creating new channels,….) was automagically done when calling a method on my client service reference?

Well using the Spring framework I’ve been able to accomplish this. You won’t need to change or add any code as long as your service is exposed with an interface. At runtime a new subclass of my ChannelManager class is created which implements the service interface. All calls are forwarded to the ExecuteInChannel method, which creates a channel, calls the method you originally wanted to execute, returns the result and closes the channel. You can also subclass the ChannelManager class to change the way you want to manage your channels.

Over the next few days I hope to add some more functionality, like channel pooling and test it a bit better. Source code will be available.


Presentation: Introduction to Spring.Net

Last Thursday my boss and I gave a presentation on Spring.Net and dependency management in general. The audience mainly, if not only, consisted of students in their 2nd or 3rd year so they probably wondered what all the fuzz was about. I just hope that they will remember the concepts we introduced to them and understand that there’s more to software development than the typical three tier applications you develop in school.

If you were in the audience and have questions on the topic or presentation, feel free to contact me at: me[at]bennymichielsen[dot]be .

The first few slides are based on and contain images from a presentation by Bob Martin and is available on InfoQ. The sample which introduces AOP and has an implementation of INotifyPropertyChanged is based on a sample you find in the Examples directory when you install Spring.Net.

Keynote Presentation:

Introduction.key (730.08 kb)

PDF Version:

Introduction.pdf (1.37 mb)


SpringSamples.zip (2.65 mb)

Add aspects at runtime without xml to your spring context

A user on the Spring.Net forum asked if it was possible to apply an interceptor at runtime to certain classes without resorting to xml. It turned out to be rather easy to accomplish this and encourages me to look deeper into enabling something like Fluent NHibernate for Spring.Net.

The key interface in this story is “IObjectPostProcessor”. It enables you to edit an object after it has been instantiated and populated by Spring.Net.

public interface IObjectPostProcessor
	object PostProcessAfterInitialization(object instance, string objectName);
	object PostProcessBeforeInitialization(object instance, string name);

The documentation states that the processors that populate entities via marker attributes should use the “PostProcessBeforeInitialization” where as postprocessors that wrap objects with proxies should use “PostProcessAfterInitialization”. In this case it’s clear that since we will create a proxy we need to implement the latter.

public object PostProcessAfterInitialization(object instance, string objectName)
	if (InstanceShouldBeProxied(instance))
		ProxyFactory factory = new ProxyFactory(instance);
		factory.AddAdvice(new WriteLineAspect());
		return factory.GetProxy();
	return instance;

The implementation is rather straightforward. The postprocessor has a collection of all the types it should intercept and checks each instance it is handed. If there is a match it will create a proxyfactory, add the advice and create a proxy. Otherwise it just returns the instance.

The application context in Spring automatically picks up any processors it has and will hook it up for you. When deployed in an objectfactory however you need to explicitly register it.

The only thing left to add now is the configuration part for the postprocessor which is demonstrated in the sample below.

private static void RegisterPostProcessor(GenericApplicationContext context)
	MyPostProcessor postProcessor = new MyPostProcessor();

Full source code is available here: Program.cs (3.50 kb)