Question

I’m learning about WCF Web Services and I’m concerned about all of the coupling that I’m seeing. The way I see it, I should be able to write a component and then use it just about anywhere – in-proc, across the intranet or from an ASP.NET page and only ever need to just change the way it’s hosted.

Once you start working with System.ServiceModel.Web though you start decorating your ServiceOperations with things like:

[OperationContract] [WebGet] string EchoWithGet(string s); 

That right there is coupling the method to the web. Can you use a contract like that in a service that’s to be hosted in-proc?

And in some of the examples I’m looking at I’m also seeing code like:

public class FavoriteMovieService : IFavoriteMovie {   MyFavoriteMovie item = new MyFavoriteMovie();    public MyFavoriteMovie GetItem()   {     if(item == null)       throw new WebProtocolException(HttpStatusCode.NotFound, 'Not found.', null);     return item;   } } 

You wouldn’t want to throw an exception like that in your service code if you were hosting in-proc, right??

Are there still good ways to write WCF web services, and hopefully RESTful ones that don’t require such tight coupling to the web? It seems to defeat the entire purpose of WCF.

I realize that I’m probably just misunderstanding something since I’m new to doing these sorts of WCF services, but I’m curious.

Please enlighten me. 🙂

Answer 1

Yes you can use that contract with a non web endpoint. It will only use the RESTful commands if you use an endpoint which recognizes this (WebHttpBinding as of .NET 3.5 sp1). Otherwise, it will behave like any other data contract. If you use named pipes, it will be fine inproc. As an aside, using the WebHTTPBinding will completely destroy the ability of of any other endpoints in your servicehost to expose metadata. If you need to do this, you should create two separate servicehosts. One for the RESTful service, and one for everything else. That was a couple of hours of debugging.

As for the error, its a bit of a contrived example. I would let WCF handle all of the communication level errors, and only throw errors that you can handle at the other endpoint. Otherwise, return a message with some sort of error code your other endpoint can actually handle. Additionally, as long as the exception leaves your object in a consistent state, just eat it and don’t fault the channel.

On a related note, I’ve found it easier to create an interface resolver object for inproc calls. It behaves (mostly) like servicehost, except that I don’t need a client, I can ask the object to resolve the interface for me. The WCF overhead is a bit large for inproc calls.