My old post about the Castle Windsor WCF facility is a bit long in the tooth, as Mr. Craig Neuwirt and others have been hard at work improving the facility. The release of Windsor 2.0 inspired me to attempt to go over the facility and highlight some of the new items. In the process, I’ll cover some basics, as even those have changed a bit. I have written most of the new documentation for the WCF facility, which needs to be reviewed by Craig since some of the new stuff is above my pay grade. The good news is that, when released, the facility will have some good documentation as well.
The best place to see the new facility in action is to grab Castle’s trunk and go thorugh the WCF Facility unit tests. They are comprehensive and give a great example of the new features of the facility. This post, and the documentation I wrote, are almost entirely based on those tests. Now, on to some examples.
Basic Server Quick Start
The basic steps to using the WCF Facility are the same, and consist of:
- Create your WCF service and data contracts.
- Create a service type, implementing your contract.
- Create your .svc file for your service.
- Configure Windsor to use the WCF Facility for your service.
Create WCF Service and Data Contracts
In this very simple example, I am only going to use a service contract. Here is my contract:
namespace MyService.Core.Interfaces
{
[ServiceContract]
public interface IMyService
{
[OperationContract]
string MyOperation1(string myValue);
}
}
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=a516a053-994a-4e6b-9421-4177e5e263aa)
So, all my operation contract does is take in a string and return a string. No big whoop.
Implement the Contract
namespace MyService.Core
{
public class TheService : IMyService
{
public string Prefix { get; set; }
public TheService(string prefix)
{
Prefix = prefix;
}
#region IMyService Members
public string MyOperation1(string myValue)
{
return String.Format(“{0} {1}”,Prefix, myValue);
}
#endregion
}
}
Create your SVC file
Presuming you have a web application to host your service, all raring to go, we need to tell the framework how to creaate your service. That’s what the .svc file does:
<%@ ServiceHost Service="my service"
Factory="Castle.Facilities.WcfIntegration.DefaultServiceHostFactory, Castle.Facilities.WcfIntegration" %>
As with the previous version of the facility, you have to use a custom ServiceHostFactory, which has changed to Castle.Facilities.WcfIntegration.DefaultServiceHostFactory. Also, the Service attribute in the .svc file needs to point to the component name in your Windsor configuration, which brings us to…
Configure Windsor
In my last post, I used Boo to configure the container. This time around, I am going to use the fluent API that Craig has created because it is kick ass. The container needs to be configured on application start, so we put the following in the Global.asax file:
#region IContainerAccessor Members
public IWindsorContainer Container { get; private set; }
#endregion
protected void Application_Start(object sender, EventArgs e)
{
ServiceMetadataBehavior metadata = new ServiceMetadataBehavior();
metadata.HttpGetEnabled = true;
Container = new WindsorContainer()
.AddFacility<WcfFacility>()
.Register(
Component.For<IServiceBehavior>().Instance(metadata),
Component.For<IMyService>()
.Named(“my service”)
.ImplementedBy<TheService>()
.DependsOn(new {prefix = “A WCF Facility Service says”})
);
}
Here, lemme ‘splain. As with any web application that uses Windsor, the container lives on the Global Application object. Here, I first add the WcfFacility followed by adding a service behavior (ServiceMetadataBehavior). This behavior will be added to all services registered with the container, however, new to the facility is the ability to explicitly scope a behavior. You can scope a behavior to: all services, all clients, or to explicit clients/services. I know that feature was oft-requested by the community and Craig is the man for getting it done. Back to our example, the service is registered is a IMyService named “my service” (remember our .svc file) and implemented by the TheService type. Finally, I pass in my constructor argument, which is a string. Oh, and in order to use the facility, you’ll need a reference to the following assemblies:
- Castle.Core
- Castle.Windsor
- Castle.MicroKernel
- Castle.Facilities.WcfIntegration
- Castle.DynamicProxy2
That’s it! The service is ready to run. You’ll notice (or maybe you didn’t), that I did not even open the web.config. You can use the web.config if you like, but I didn’t here because I am lazy. You also may have noticed that I did not specify an endpoint or binding, so the facility created a default endpoint with BasicHttpBinding. Again, I am lazy, but that is cool.
Show Me the Service
The image here shows what the service looks like in the WCFTestClient.exe application.
Easy peasy
The default protocol is SOAP (does anyone use SOAP anymore?) but you could easily create a REST endpoint. Maybe I’ll show that in my next post about this stuff. This post only covers the very basics, so if you have more complicated stuff, I can take a stab at it or maybe ask Craig.
Just to be complete, here are most of the big time new features:
- Scoped Behaviors
- The ability to create service hosts and control the host life cycle (see IServiceHostAware)
- Fluent API
Speaking of which, lemme know if there is anything specific you want to see concerning the WCF Facility. As I mentioned, the unit tests in the castle trunk are pretty comprehensive and the forthcoming documentation will have tons of configuration examples. Try it out, it makes managing dependencies with WCF a breeze.
