WCF Web Smackdown - Round 2

WCF Web Progamming 1. Jef 0.

OK. So, I picked myself up, dusted off, and got ready for round 2. Now that I have been sufficiently schooled on the virtues of WebServiceHostFactory, I am ready for my next baby steps. But first, I wanted to demo the simple service and do a quick review. I ripped out all of the <system.serviceModel> configuration, slammed in my factory attribute on the servicehost directive:

<%@ ServiceHost Language=C# Debug="true" Factory="System.ServiceModel.Web.WebServiceHostFactory" Service="Improving.Samples.WCF.Web.Hello" %>

using System.ServiceModel;

using System.ServiceModel.Web;

 

namespace Improving.Samples.WCF.Web

{

    [ServiceContract()]

    public class Hello

    {

        [OperationContract]

        [WebGet()]

        public string Say()

        {

            return "Hello, Cruel World";

        }

    }

}

 

read another blog post from Steve to be on the safe side, and hit f5.

 

 

Ha. Oops. So, I actually know what this problem is. In WCF, endpoints don't map to Services but rather to methods. So when I browse to /Service.svc, I am not actually addressing an endpoint, I am addressing a class that contains methods that are exposed as endpoints in WCF terms. I can fix it by appending the method name to the URL (/Service.svc/Say):

 

I can also (almost) fix it with a wildcarded UriTemplate, but we'll save that for tomorrow. As mentioned, the model is currently a little picky about trailing slashes, so /Service.svc/Say/ yields the first image above.

 

Now.

 

If we revisit the service contract defined above, the only thing excluding the WebServiceHostFactory that is specific to ol' Webby is the WebGet attribute. If we look at the web get attribute, it defines a couple of public properties that allow us to shape the messaging a bit, BodyStyle and UriTemplate. We'll take a glance at BodyStyle first.

 

BodyStyle is an instance of the enumeration type, WebMessageBodyStyle:

public enum WebMessageBodyStyle
{
    Bare,
    Wrapped,
    WrappedRequest,
    WrappedResponse
}

Bare is the default value, and results in the <string ... /> encoding you see above in the browser. It would be a lot more interesting with a more interesting serializable type. WebMessageBodyStyle.Wrapped returns something like:

 

 

WrappedRequest and WrappedResponse give you control over the individual messages. I won't demonstrate those further.

 

I'll look a little more closely at UriTemplate tomorrow. Following that, I want to pllay around with basic HTTP types of things like cache awareness, content negotiation, json, status codes, headers, chunked encoding, streaming, async models, etc. Once we get all of that squared away, I'll start using the API to do "real" stuff. Then I'll dig into the syndication support, etc.

 

Quick review: Currently, I think that IHttpHandler has a slight leg up on WCF in terms of simplicity and adhering to the principle of least astonishment. One thing I do get from the WCF web programming model is serialization to and from .NET types. That is pretty cheap with DataContractSerializer, XmlSerializer, and friends. Another thing that I get is a more simplistic method of mapping HTTP methods to .NET methods, so I can avoid having a Servlet-like interface and I can avoid writing a switch statement. The Microsoft namespace for serialization is interesting, but I would want to avoid that. It's a bit too leaky an abstraction for me, though I suppose I grok why it's there. We haven't done anything terribly interesting yet, so I am still feeling very positive about the WCF web programming model. There's some good stuff under the hood. UriTemplates, for example. Looking forward to it.

Comments

[Steve Maine]

Thanks Jeff -- keep it coming. One minor point of clarification -- your comment "In WCF, endpoints don't map to Services but rather to methods" isn't quite correct. Our dispatch model is deeply based on the idea of prefix matching -- an endpoint actually listens on the set of all URI's that start with a common prefix (just like a channel does). Within the URI space of the endpoint, we use URI templates to carve up that space and hand parts of it out to different implementation methods on the service. That's how we look at the world on the server, where it's important to keep in mind as it relates to instancing and concurrency behavior. From the outside looking in (i.e. from the client's perspective), it doesn't really matter much if you want to think of 1 service listening on a bunch of URI's or a bunch of logical "services" each listening on a single URI. The distinction doesn't matter so much on the client because it's insulated from those server-side implementation details. Couple more things -- if you want to eschew the serialization stack entirely and just write out strings, you can take a look at the "push style streaming" sample which shows you how to implement asp-net style response.Write(). That sample has a bit of plumbing in it at the moment, but we plan to make that scenario first-class by the time we ship. Finally, in this build operations using UriTemplate="*" or UriTemplate="" will require an trailing slash (service.svc/ vs service.svc)