The problem with conjuring tricks is that they lose practically all their glamour once you find out how they are done.  It's very cool to see David Blaine walk down the street, do a few passes over his hand, and resurrect a fly which proceeds to flee.  It's rather disappointing to do a google search and discover that in order to prepare for this trick, the first requirement is that you freeze a fly.

My trick is to make an autocomplete extender from the Ajax Control Toolkit call a WCF service instead of an asmx service.  For this recipe, I assume that you are already familiar with the autocomplete extender, and that you are using Visual Studio 2008.  I warn you in advance -- my trick disappoints.  It is so trivially easy that, once the technique spreads, it is very unlikely to impress your colleagues at work, much less get you a date with a supermodel.

Two important WCF resources came out last week.  The first is the source code for StockTrader 2.0, Microsoft's reference app for .NET 3.5 using, in particular, CF and PF.  The download is available here http://msdn.microsoft.com/en-us/netframework/bb499684.aspx.  This is fairly significant since there are not (as far as I have been able to tell) any guidelines generally available on how to build a distributed application using the Communications Foundation.  In the project I am currently working on, we have been trying and stopping as we go, trading frequent emails with various Microsoft insiders to try to find out if what we are doing makes sense (so far it has). 

Now we have the opportunity to compare our app against StockTrader and see where the differences lie.  I'm not sure if this is an artifice or not, but I like being able to take two ideas and decide which one better as I work through an architecture.  This is a necessary exercise in working towards the "right" architecture.  The approach resembles, in some ways, the Mirror of Nature that Richard Rorty made his name on attacking, except that it is concerned with practice rather than with epistemology.  I think that there is a right way to do things of which I am unaware.  To use Don Rumsfeld's memorable phrase, it is one of the things I know I don't know.  I then work, through trial and error as well as a comparison of alternatives, towards an intellectual representation of what that correct way of getting things done might be. 

I've talked to other developers who feel that speaking about the "right way" to do things is simply a trap we all fall into or, worse, a fiction that serves only to generate artificial conflicts and slow down actual development.  As one developer told me, "There are many arguments on either side of any issue, and we're not going to be able to resolve here which ones are better, since we come to it with preconceptions and prejudices we can't get over easily."  While visiting my brother at college once, I attended a lecture in which Alan Dershowitz, the civil rights lawyer, argued very much the same case.  He insisted that he could go about seven levels behind any argument, and then seven levels behind the case against him.  The peeling of levels (usually it only takes two or three) gives the false impression that we are actually getting to the bottom of things, whereas Dershowitz himself had reached the point in his career where he felt it was merely an exercise in cleverness for lawyers and for philosophers an exercise in futility.

This may all be true, and yet I feel I need this fiction, if it is a fiction, in order to do my job well.

The second important release this week is Juval Lowy's presention on WCF: Beyond the Endpoints (you will need to have Microsoft Live Meeting installed to listen to it).  In this presentation you will come to realize what many people already know: Mr. Lowy is either a genius or a madman, and had he lived in another era, he would have made a good Jules Verne villain.  Based on his WCF book, I had taken his position to be that CF solves many distributed programming problems, and in the big picture serves as the fulfillment (or successor) to component based programming -- the notion that based upon common and established conventions we can pass messages between disparate technologies.

In Beyond the Endpoints, Mr. Lowy tops even those grand pronouncements.  Here he argues that CF is actually the successor to all of our current .NET programming conventions in C# and VB.NET, and is in fact a new programming model.  With specific examples from the Singleton pattern to class level isolation, he demonstrates various low level ways in which WCF provides better ways to do our most common programming tasks.  He makes clear in the Q&A session afterwards that he basically sees something in CF that even Microsoft doesn't see in their technology.  His vision for WCF veers wildly away from Microsoft's vision.  When asked what the performance penalty for using CF as a programming model would be, he insists that sending messages over a wire in WCF is actually faster than working with traditional in-proc objects (given certain unspecified conditions).  Moreover, the performance cost is irrelevant.  Mr. Lowy appeals to history in order to explain his vision for CF.  COM, for instance, started off as simply a way to embed files inside of Microsoft Word documents.  In order to get Object Linking and Embedding to work, however, Microsoft's engineers were oblige to solve fundamental problems that in turn produced what we now know as COM.  CF, for Juval Lowy, is headed very much along the same track.

It is a truly amazing presentation, ambitious in scope and broad in vision, and I highly recommend it to anyone interested in the inherent potential of the Communications Foundation.

What is SOA?  It is currently the hottest thing going on in corporate technology, and promises to simultaneously integrate disparate applications on multiple platforms as well as provide code reuse to all of those platforms.  According to Juval Lowy, it is the culmination of a 20 year project to enable true component-based design -- in other words, the fulfillment of COM, rather than merely its replacement.  Others see it as a threat to object oriented programming. According to yet others, it is simply the wave of the future.  Rocky Lhotka recently remarked at a users-group meeting that it reminds him of mainframe programming.  In Windows Communication Foundation Unleashed, the authors write somewhat uncharitably:

"Thomas Erl, for instance, published two vast books ostensibly on the subject, but never managed to provide a noncircuitous definition of the approach in either of them."

This diversity of opinion, I believe, gives me an opening to offer my own definition of SOA.  SOA is, put simply, the triumph of the Facade pattern.

In the 90's, Erich Gamma, Ralph Johnson, John Vlissides and Richard Helm popularized the notion of the 23 fundamental design patterns of object oriented programming.  I've often wondered why they came up with 23 patterns.  Some, such as the Flyweight pattern, are simply never used.  At the same time, one of the most popular patterns, MVP, doesn't even make the canonical list.  How did they come up with 23?

Here's an article on the significance of the number 23 which may or may not shed light on the Gang of Four's motivation.  In Peter Greenaway's A Zed and Two Noughts, the characters become obsessed with the number 23, and claim that there are 23 letters in the Greek alphabet and that Vermeer created 23 paintings (both false, by the way).  Perhaps the Gang of Four are Discordians -- Discordians are fascinated by what they call the 23 Enigma.

In any case, they came up with 23 canonical (or "fundamental" or "classic") design patterns, and in the past decade, knowing these patterns has become the unofficial dividing line between the common run of code monkeys (I use the term affectionately) and so-called "true" developers -- the initiation rite that turns boy programmers into men.  Anyone in development who wants to be anybody makes the attempt to learn them, but for whatever reason, the 23 patterns resist the attempt -- sometimes because it is difficult to see how you would ever actually use them.  It helps, however, to remember that the StringBuilder type in C# is based on the Builder pattern, and that the Clone method on most types implements the Prototype pattern.  Delegates are built around the Observer pattern and collections are built around the Iterator pattern -- but since these are both basically part of the C# language, among others, you don't really need to learn them anymore.  In my opinion, the most useful patterns are the Template and the Factory Method.  The Singleton pattern, on the other hand, starts off seeming like a useful pattern but turns out not to be -- a bit like a bad joke one eventually tires of.  It is, however, easy to remember, if somewhat tricky to implement.

The one pattern no one ever fails to remember is the Facade pattern.  It doesn't do anything clever with abstract base classes or interfaces.  It doesn't have tricky implementation details.  It simply takes the principle of encapsulation and goes crazy with it. Whatever complicated code you have, you place it behind a wall of code, called the Facade, which provides methods to manipulate your "real" code.  It's the sort of pattern which, like Monsieur Jordan, once you find out about it you realize you've been doing it all your life.  The simplicity and ubiquity of the Facade makes it an unattractive pattern -- it takes no programming acumen to learn it; it requires great effort to avoid it. It is the dumbest of the 23 canonical design patterns.

And Service Oriented Architecture is all built around it.  In some sense, SOA marks the democratization of architecture.  There are still tricks to planning a good SOA, and securing it may require some sophistication -- but with SOA, anyone can be an architect.  Well ... anyone who can build a Facade.