thinking-out-loud

WCF Web Ask

So a couple of proposals, a presentation at a internal conference, and some work on our [long overdue] website makeover, I am ready to start playing with the WCF Web programming model some more. Two things immediately come to mind. I am going to address the first one here.

So, if you've never had the distinct pleasure of working directly with softies, you may not recognize a peculiar quirk of their culture, an "ism" if you will. That quirk is the tendency to convert verbs into nouns. So, if you are working with a client that has an incumbent non-MS infrastructure, then you are working a "compete." If you have a question or request or favor, it is often referred to as an "Ask."

SO.

This is an ASK.

I want an ognl or xpath-like syntax in uri templates to allow me to map down into object. So, instead of:

        [OperationContract]

        [WebInvoke(Method = "PUT", UriTemplate = "/customer/{id}" )]

        void PutCustomer(int id, Customer customer );

I could instead have

        [OperationContract]

        [WebInvoke(Method = "PUT", UriTemplate = "/customer/{customer.id}" )]

        void PutCustomer(Customer customer);

This might also be helpful when I use post to create a new customer, e.g.

        [OperationContract]

        [WebInvoke(Method = "POST", UriTemplate = "/customers" )]

        [Location(UriTemplate = "/customer/{return.id}" )]

        Customer CreateCustomer(Customer customer);

Note that the location header does not exist currently. It is my suggestion of how you might specify the location header when a resource has been created via POST. I threw "return" in there as a variable to reference the return value. The idea is definitely half-baked at best, but I think that, given that we're using HTTP as the contract here, and HTTP says return a location header, then it makes sense that we provide a way in the contract to handle that.

I think it would also be interesting to modify the template behavior to adopt some uri conventions codified in Sam Ruby and Leonard Richardson's new book Restful Web Services. From Udell's post:

"[use] commas to encode ordered siblings (/parent/child1,child2), and semicolons to encode unordered siblings (/parent/red;green)."

So, we could do something like GET /customers/1,2,3,4,5, and receive back the customers specified by the list, e.g.

        [OperationContract]

        [WebInvoke(Method = "GET", UriTemplate = "/customers/{ids}" )]

        List<Customer> CreateCustomer(int[] ids);

I hope that you find that useful feedback.

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.

Thank you

Steve gave me the course correction I needed. Thank you thank you thank you. So, I'll try to get back to the Smackdown shortly. In the meantime, I wanted to overemphasize a point on the libraries. Steve mentioned this already but *please* *please* don't let the fact that these assemblies are folded into the Biztalk Services SDK deter you from using them. Neither the very cool services that you can interface with via the Biztalk Services SDK or the WCF web programming model require licenses for Biztalk.

Don Box had a really funny bit on how shipping software at Microsoft is like getting riders on bills in the US Legislature, and that they just wanted to set ol' Webby (as I've taken to calling the WCF Web programming model) free it to the world rather than sweat the particulars of the 'branding' of the vessel on which it was freed.

Some Interesting History

Here's a little bit of fiction for you, with a prefaced disclaimer. I'm not anywhere near claiming that these thoughts are moderately well-formed.

"Hey, this web stuff is cute. OK, back to the real stuff. [CORBA, DCOM], anyone?"

"Hey, what the !*@&#^#? I can't connect my [CORBA, DCOM] over the net. Hmmm...."

"Hey! If I could just go through port 80, I could connect my [CORBA, DCOM] bits over the internet. Cool!"

"HEY!?!?! Why is this firewall looking at my content? Argh."

"Hey! What if, instead of IIOP, I encoded this stuff as XML? It'll be slow, but .... COOL!"

 "Hey, what would be great is if I had a generalized envelope so that I could add in a bunch of orthogonal features like transactions and security and reliability! But what to call it? ... How about, um, SOAP? Cool!"

"Hey. What would be great is if I had a nice, generalized OM for distributed programming that sits on top of all of this infrastructure so that I can almost transparently switch between programming models and stuff. That's be cool! I'd rule the world! What do I call it? Hmmm.... how about, um, 'Indigo?' Cool!"

"Hey -- how the $&%^% to we do HTTP GET?"

D'oh. I find this interesting. So, basically, at the end of the day, there is a baseline understanding of how the web was designed and currently works that was largely ignored/dismissed in the soap world and specifically in the Connected Systems Division until this Biztalk SDK. Many of us, myself included, drank to kool-aid on soap early on, because we wanted to connect systems together, and we liked messaging or we liked distributed objects, and we didn't stop long enough to grok fully the web. As I did more web stuff, I realized that I didn't really care about a lot of the stuff that was layered into the SOAP/WS stack, and I did really need and love the beauty of GET and friends.

Do we need SOAP? Sometimes. Maybe. It is nice for layering in security when transport security isn't good enough.

Do we need contracts? Sometimes. Maybe. It can help make the services and resources more accessible to the broad mass of developers. But in many cases, the service provider ships SDKs as well, and that makes the contract less necessary at the expense of coupling. Also, you often get a set of examples of documents, and you just 'hack something up.' Often, the contracts that are already out there (HTTP, RSS/ATOM, etc.) are good enough.

So, it is interesting to me to watch guys like Clemens Vasters and Don Box (and Steve Maine, though I think he was less heavily involved in 'expectorating' the WS-splat and a lot more heavily involved in consuming and evangelizing prior to getting into the big house) starting to shed the WS-Splat baggage and just GET it. And I think that they are being pragmatic about it and trying to scratch the 80% itch (GET) really well, but they are adding in a decent set of support for the REST (ha, pun, ha ha, er, um...) of the story without being to religious about being RESTful. And when questions come up like [paraphrased] "Well, shouldn't you layer soap into that?" they look very relaxed and calm as they say [paraphrased] "Nah, you're not going to need it here." From the outside, it looks a little cathartic.

Ron over at ZapThink says:

The real challenge to applying REST as a means to implement loosely-coupled Services is that REST has no explicit contract to define behavior, which means that all behaviors are implied. In REST, the data pumped through a GET, PUT, or POST operation contain all the semantics necessary to understand how a Service behaves.

Therefore, REST isn’t appropriate for organizations that wish to take a contract-first development approach aimed at maximizing reuse and composition, in addition to loose coupling. And that’s the rub with REST – SOA aims to reuse not just the resource, but also the operation and the composition as well.

[Emphasis mine.]  Hmmm. I was thinking that the contract is explicit (for purists or pragmatists). Of course, I don't work for a research firm, so there you go.

"Data pumped." He makes it sound as if the data is encoded with the application semantics and is merely being "tunneled" over HTTP rather than the application is using HTTP to broker the application state. Oh wait, but isn't that SOAP? File under 'M' for misunderstanding. Ron, here's a suggestion for some research. Pick a problem worthy of a services and/or restful solution. Solve it twice, once with REST and once with WS-splat. Hire some high-priced consultants to help you get each "right," if necessary. Publish the results. Boy, now that would be nice.

RESTful Servlets

I was digging through some Java code and noticed a servlet coded in the following manner:

public class SomeServlet {

public void doGet(HttpServletRequest request, HttpServletResponse response){

doPost(request, response);

}

public void doPost(HttpServletRequest request, HttpServletResponse response){

// do something interesting

}

}

It would be more RESTful to do this the other way around, which is to say, it is ok for doPost to call (i.e. have the same semantics as) doGet. The more important point, though, is that as long as the semantics are correct on the wire, then it is still RESTful even if it isn't implemented in a manner than conveys the conformance to semantics.

MMM: RSS + OPML + TV

Clemen's projects are always so cool. Do you take Visa?

It is interesting that he is going POX/REST-ish, especially given a previous missive, but it is the perfect choice. 

Will the real 'thinking out loud' please stand up?

Heh. Sadly, we may both need to stand in line. I am sure that Tim's got tenure, and besides, I really want to rename mine to "things i've likely forgotten." Alas, typepad warns against such renamings.

Now, if only you can help me understand REST in the context of security (specifically, confidentiality).

If you use TLS, of course, then you get the confidentiality, but lose the visibility, cacheability, etc, that contribute so well to the scalability. However, if you want confidentiality, then you obviously don't want visibility, and it is likely that you do not want the cacheability either.

An alternative to TLS would be to encrypt the payload, but leave the headers in tact. S/MIME, PGP-MIME, WS-Security. Sounds familiar. An unscruplous attacker may track your requests and infer meaning from the uris that you access, but that could be alleviated via limiting access to a single uri between parties. And you could limit the requests to the good ol' "Do Something" method of choice, POST. If you want to actually target a different uri (and method?), then that would be included in the encrypted content. D'oh. Now we're starting to sound like web services, eprs. I am sure I am missing some key bits. Help, please.

It seems to me that this is a question of interest to enterprises conducting or thinking about conducting confidential business over the internet. It also seems to me that it could call in to question the importance of visibility and cacheability for scalability on the internet, or perhaps more correctly, could call into question just how important or perhaps [im]possible "internet scale" is to business interactions that require confidentiality. Ebay might disagree.

It is likely that I have already forgotten this.

Visibility and REST v. Security

Fair warning: Half baked thoughts ahead.

Mark Baker counts as thought leader for me, esp. subtopic REST. He rails on the importance of visibility in internet scale systems in a recent post. So, this is for you, Mr. Baker: What is your opinion on HTTP's Connect and SSL/TLS tunneling in light of the need for visibility as a key enabler of internet scale? Doesn't security (specifically confidentiality) throw a pretty huge monkey wrench into the nice properties visibility affords the architecture? There is a lot of data that can flow cleartext, but businesses don't like it as much in my experience. I know I have seen Mr. Fielding highlighting the issue as something to attend to.

Once you are inside the firewall, is the term "internet-scale" really material anymore? Especially in the sense that the internet is a collection of autonomous but interconnected networks? That is, the relevant bits wrt internet scalability are the messages flowing between the firewalls. It would seem that the majority of the visibility necessary to gain the scale qualities in the architecture exist at the tcp and, more importantly, ip levels rather than the http levels (in spite of the increased semantic visibility provided by a RESTful protocol). I think that web services would benefit from that visibility as much as the REST.

Pub/Sub, REST style

This is the second time I have run across pubsub.com, and it seems interesting and relevant to some of my recent posts, so here you go. They have a RESTful service api for pub/sub rss news feeds. Very cool. I want to take the time to dig in to their API, but I am tired.

So tired.