jump to navigation

Creating a REST Service with WCF and Windsor May 11, 2009

Posted by ruprict in WCF, Windsor.
Tags: , ,
add a comment

Following on from my previous post, here is a short post showing how quickly you can create a REST based service using the WCF Facility for Castle Windsor.   We will use the same service contract and implementation as the last post, with some very minor changes (only one, actually).    The list of steps to expose our service from the previous post with a REST endpoint consists of:

  1. Create a new .svc file for the second endpoint.
  2. Add an attribute to the operation contract to specify what HTTP verbs are allowed.

That’s it.  Please note that we are not replacing our SOAP endpoint from before, nor are we changing the configuration of the WCF Facility, nor are we touching the web.config.  The changes below will highlight how little we need to do.  Here is the new service endpoint (.svc file):

<%@ ServiceHost Service="my service"
Factory="Castle.Facilities.WcfIntegration.WindsorServiceHostFactory`1[[Castle.Facilities.WcfIntegration.Rest.RestServiceModel,
Castle.Facilities.WcfIntegration]], Castle.Facilities.WcfIntegration" %>

All we have done here is replace our factory with the REST aware service model from the WCF Facility.  We are using the Service attribute to point to the same component as the SOAP endpoing.

And the new service contract:

[ServiceContract]

public interface IMyService

{

[OperationContract]

[WebGet]

string MyOperation1(string myValue);

}

We’ve added the System.ServiceModel.Web attribute [WebGet] to allow HTTP GET to this endpoint.  Now, our operation is availalbe as a REST endpoint, using a URL like so:

http://server/site/rest.svc/MyOperation1?myValue=I%20am%20RESTful

which returns

<string>A WCF Facility Service says I am RESTful</string>

It’s likely that you wouldn’t want applicaiton/xml to be the default return content-type, but the point of this post is not to show a best practice with REST, but to show how bleeding easy it is to expose a REST endpoint.  We are also now exposing TWO endpoints (SOAP and REST) with a singular service implementation, a detail worthy of note.  In the real world, you would likely have a service manager that registered service implementations and formatters, allowing the clients to specify a return type (XML, JSON, etc) and amending the content-type accordingly.

This, however, is my blog and could not be farther from the real world. ;)

WCF and Castle Windsor Update May 7, 2009

Posted by ruprict in Castle, WCF, Windsor.
Tags: ,
1 comment so far

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:

  1. Create your WCF service and data contracts.
  2. Create a service type, implementing your contract.
  3. Create your .svc file for your service.
  4. 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]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

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.

Castle Windsor and WCF: A Match Made in Heaven April 1, 2008

Posted by ruprict in WCF.
Tags: ,
6 comments

(Note: I’ve been out for a bit due to new recent additions to my life. The first was a (third) daughter born 2 weeks early and the second is an aggressive vasectomy schedule. Too much information, you say? I agree.)

If you’ve read any of my other posts, you know I dig Castle Windsor. It’s cool and allows a “special” developer like me to look pretty smart without actually being all that smart. I also really like WCF, as I feel it lead the charge of “things Microsoft started getting right”, again helping me look smart by abstracting all the WS-*** and other service gobblety-gook out of my life. Since I REALLY like both of these technologies, I was hesitant to put them together, fearing I couldn’t take the shear joy it would create. However, Ayende and Craig have created the WCF Facility, allowing me to register my services on the Windsor container, and thus use dependency injection to handle all the stuff my services need. This post is a (hopefully) quick “how to” on this really cool facility.

(Note: This is my first foray into using Binsor for Windsor Configuration. All the smart guys were using it while I was still XMLing in the dark ages, so I had to follow suit.)

Step Uno: Write a Service

Let us create a simple WCF service. It looks like:

[ServiceContract()]

public interface IService1

{

[OperationContract]

string MyOperation1(string myValue);

[OperationContract]

void ThrowError();

}

public class Service1 : IService1

{

private ILogger logger; //Yes, yes, should init to a NullInstance.

public ILogger Logger

{

get { return logger; }

set { logger = value; }

}

#region IService1 Members

public string MyOperation1(string myValue)

{

logger.Info(“MyOperation1 called with {0}”,myValue);

return “Hello: “ + myValue;

}

public void ThrowError()

{

throw new Exception(“AAAAAAH!”);

}

#endregion

}

So, you see the service contract, you see the implementation. Please notice the following details:

  • I added an ILogger property. This is a dependency.
  • There is a method that just ralphs an error. Usually I am not as obvious with my errors, but at least I will be able to debug this one.

Usually, at this point, you’d open up the web.config file and start writing mountains of <service> tags and <behaviors> and all that. We aren’t going to do that. We are going to bring in Windsor to take care of all our needs. Yay!

Bring in da Noise, Bring in da Windsor

I am going to presume that you, the reader, knows about Windsor and, at least at a high level, how to configure it. Basically, for a web app (we are gonna host our services in IIS) you need to:

  • Write the configuration files for Windsor, consisting of properties, facilities, and components. Go read the castleproject.org site for some decent examples.
  • Register the container at startup.

As I stated previously, I am using Binsor to write my config files. (Tangent: I need to learn Boo. Ayende, is that book done yet?) Here goes:

import System;

import System.Reflection

import System.ServiceModel

import System.ServiceModel.Description from System.ServiceModel

import Castle.Facilities.Logging

import Castle.Facilities.WcfIntegration

import Ruprict.Grok.Castle.WcfIntegration.Core

facility LoggingFacility:

loggingApi = LoggerImplementation.Log4net

configFile = ‘log4net.config’

facility WcfFacility

component ‘windsor.service’, IService1, Service1:

ServiceModel = WcfServiceModel().Hosted() \

.AddEndpoints(WcfEndpoint.BoundTo(BasicHttpBinding()))

component ‘error.handler’,IServiceBehavior, LogExceptionHandler

component ‘metadata.behavior’,IServiceBehavior, ServiceMetadataBehavior:

HttpGetEnabled = true

This is Binsor 2.0 syntax, which is (from what I understand) yummier than ever. I do like it. It’s compact and readable and I don’t end up getting errors b/c I forgot to close a tag. Looking at the import statements, you see I bring in whatever namespaces I need, including my service namespace and any of it’s dependencies. Here, I’ve yanked in the ServiceModel stuff from WCF so I can hook up my IServiceBehavior extension classes, as well as some other Castle Facility namespaces (namely, the Logging facility). Then, I start defining things. I grab the LoggingFacility from Castle, telling it I am using Log4Net and pointing it at the right config file. Then it’s on to the star of our show, the WcfFacility. It seems odd that it just takes two words to bring in a facility that does so much. Ahh, simplicity, you are truly beautiful. Anyhoo, the first component is my WCF service (line 16) where you can see that I add a singular endpoint, bound to the BasicHttpBinding, um, binding. (NOTE: If you are using the BasicHttpBinding, like I am here, you don’t even have to specify a service model, as the facility will deduce it from the base address.) Finally, I add 2 more components, both IServiceBehaviors. For those that don’t know, IServiceBehavior is a way to extend WCF by create custom service (there are also endpoint and operation behaviors, all of which are treated the same by the WcfFacility) behaviors. In our example, I have created a LogExceptionHandler that will log errors to a log file. I also used a WCF core service behavior, ServiceMetatadataBehavior so I can use an HTTP GET to look at the service WSDL.

With the configuration defined, we have to get our IIS web app to use it, right? That’s done in the Global.asax by putting some code in the HttpApplication.Application_Start event.

public class Global : HttpApplication, IContainerAccessor

{

private static IWindsorContainer container;

protected void Application_Start(object sender, EventArgs e)

{

container = new WindsorContainer().Install(BinsorScript.FromFile(“windsor.boo”));

}

protected void Application_End(object sender, EventArgs e)

{

container.Dispose();

}

#region IContainerAccessor Members

public IWindsorContainer Container

{

get { return container;

}

#endregion

}

That single line in Application_Start tells Windsor that I am using Binsor and the name of my config file. Gorgeous!

Now, in order to host a WCF service in IIS, you need a .svc file as an endpoint, and (usually) web.config configuration sections out the yin-yang. We still need the former, pointing it to our WindsorServiceHostFactory and using the name from our Binsor config file.

<%@ServiceHost Language=”C#”

Service=”windsor.service” Factory=”Castle.Facilities.WcfIntegration.WindsorServiceHostFactory”

%>

Now, when we crank up the application, the Windsor Container will attach the IServiceBehaviors in the config to our services, automatically wiring up my LogExceptionHandler and ServiceMetadataBehavior. This is especially sexy when you have multiple services in a single application and they ALL get the behaviors. Furthermore, since my service has an ILogger property (remember that?) and I am also using the LogFacility, it will create my Log4Net logger and give my service an instance. POW! BLAM! KABLOOEY! This is how we do it.

I was going to put some examples of the service getting called using WcfTestClient.exe (free with .NET 3.5) so you could see my error behavior doing it’s thang as well as prove to you that we don’t need no stinking web.config sections, but I find them superfluous in a post that already is larger than I wanted it to be. If you have more questions, hit me with a comment.

So, in summary, the keypoints here are:

  • Windsor rocks, and the WcfFacility is all that and a bag of chips.
  • You can have web.config <service> section-less WCF services, complete with auto-wired behaviors and dependencies.
  • Ayende and Craig are really, really smart.

More Examples

These two posts (here and here) in the Castle Dev Google Group go through some more examples from Craig. You’ll even get to see me asking very basic questions. Also, Craig has promised he will post some stuff focusing on the client side of things, which should be very interesting.

Update: Another, example of the newer (2008/12/02) stuff here.

Reblog this post [with Zemanta]