WCF and Castle Windsor Update
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 StartThe 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 ContractsIn this very simple example, I am only going to use a service contract. Here is my contract:
Implement the Contract
Create your SVC filePresuming 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 WindsorIn 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: 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:
Show Me the ServiceThe image here shows what the service looks like in the WCFTestClient.exe application.
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