2007.05.08

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:

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:

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.

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.

2007.05.03

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.

2005.03.16

Don Box let the indigo doc cat out of the .net bag. You can also get the latest CTP from subscriber downloads if you have coughed up for the msdn subscription. The world is one step closer to becoming a better place for soap lovers everywhere [as long as you're on the ms platform :)].

2004.05.20

Several Microsoft Bloggers have been spreading their meme of the Four Tenets of Service Orientation. As Alan Kay once said, "The best way to predict the future is to invent it." MS is pushing the four tenets like your first, free rock. Like em or not (confession: I do, especially lately), MS are going to be a huge player in the SOA space by virtue of the fact that their platform will be dripping of the stuff in the next few years. If you are an enterprise architect or an integration architect, you are going to be using it, dealing with it, loving it, loathing it.

Either Service’s location can change at (almost) any time due to the fact that they’re dynamically addressable

The services communicate through dynamically negotiated communications channels that support the necessary formats and capabilities (security, reliability, etc)

Neither Service requires knowledge of each others’ internal workings in order to exchange data – they only need the published schemas & contracts

Neither party make demands on each other as to how the work is carried out

For Explicit Boundaries, Expensive Traversal, he argues:

A communications channel is dynamically negotated between Services based upon Policy which of course requires some work, the speed of which process is gated by the slowest party in the negotiations. And let's not forget the physical aspects of data marshalling, buffer copying, passing through the network stack, serializing onto the wire, navigating ethernet to the other end of the wire and then bubbling back up through all the network, OS and platform stacks.