• Monday @ Gamefest, the XNA team announced XNA Game Studio 2.0. The two big new things are support for the entire VS product line (1.0 only works on VC# Express) and the addition of networking APIs. Let’s Kill Dave has a good wrapup of the announcements from Gamefest Day One.
• Speaking of Xbox 360, I played thru the demos of Stranglehold and Bioshock. Two thumbs up on both. It’s gonna be an expensive year for Xbox gamers.
• Mark Cuban noodles on taking your house public. “Why not create a market or exchange where homeowners can sell equity in their homes?” I’ve thought about this myself from time to time. However, Mark thinks making it happen would “probably take the country’s biggest banks working together”. I wonder if there’s a more Web 2.0 social lending approach that would work better.
• Jeff Atwood calls virtualization as “the next great frontier for computer security”. I agree 100%. But I don’t think the action is going to be in “full-machine” virtualization like Virtual PC. Rather, it’s going to be sandbox virtualization. Jeff mentions GreenBorder (now part of Google) but it’s not the only solution. Some time ago, Microsoft acquired SoftGrid which uses sandbox virtualization for application deployment, but using SystemGuard for security sandboxing seems like a logical step.
• The WCF LOB Adapter SDK has released. Sonu Arora has the details. As part of the Integration team @ MSIT, I have a feeling we’re going to become fairly familiar with this technology. (via Jesus Rodriguez).
• Speaking of Jesus, he thinks the six new SCA4SOA committees are “going to help”. Why? Because inventing technology in committee has turned out so well in the past?
• John deVadoss cements BPM’s fad du jour status by contrasting “big” BPM and “little” BPM. It’s fairly obvious to me that big *anything* just doesn’t work in the enterprise. But I worry that little *anything* doesn’t work that well either. So how long until someone (probably Nick) starts arguing for “middle out” BPM?
• David Bressler wonders “What is it about registries that everyone thinks is a panacea for all things SOA?” Amen, Brother! Joe McKendrick claims it’s required for governance, but then gets to what I think is the *real* reason for focus on registries: the “registry is a tangible offering” that vendors can sell. Just because it’s productizable doesn’t mean you need it.
• Hartmut Wilms responds to my retire the tenets post, but he seems to contradict himself. On the one hand, he suggests that “the four tenets just expressed, what “almost” everybody outside the MS world knew already”. But then he goes on to dispute that the SO paradigm shift has even occurred! Hartmut, I’ll grant you that WCF (among other similar stacks) are way too focused on “you write the classes, we’ll handle the contracts and messages”. On the other hand, if you don’t provide a productive interface that most everyone can pick up and run with, the technology won’t get adopted in the first place.

John Heintz and I continue to be in mostly violent agreement. It’s kinda like me saying “You da architect! Look at my massive scale EAI Mashup!” and having him respond “No, you da architect! The SOA tenets drive me bonkers!” Makes you wonder what would happen after a few beers. What’s the architect version of Tastes Great, Less Filling? ^[Not that you would catch me drinking Miller Lite. Ever.]

Speaking of the tenets, John gives them a good shredding:

Tenet 1: Boundaries are Explicit
(Sure, but isn’t everything? Ok, so SQL based integration strategies don’t fall into this category. How do I build a good boundary? What will version better? What has a lower barrier to mashup/integration?)

Tenet 2: Services are Autonomous
(Right. This is a great goal, but provides no guidance or boundaries to achieve it.)

Tenet 3: Services share schema and contract, not class
(So do all of my OO programs with interface and classes. What is different from OO design that makes SOA something else?)

Tenet 4: Service compatibility is based upon policy
(This is a good start: the types and scope of policy can shape an architecture. The policies are the constraints in a system. There not really defined though, just a statement that they should be there.)

Ah, I feel better getting that out.

As John points out, the four tenets aren’t particularly useful as guidance. They’re too high level (like Mt. Rainier high) to be really actionable. They’re like knowing a pattern’s name but not understanding how and when to use the actual pattern. However, I don’t think the tenets were ever intended to be guidance. Instead, they were used to shift the conversation on how to build distributed applications just as Microsoft was introducing the new distributed application stack @ PDC03.

John’s response to the first tenet makes it sound like having explicit boundaries is obvious. And today, maybe it is. But back in 2003, mainstream platforms typically used a distributed object approach to building distributed apps. Distributed objects were widely implemented and fairly well understood. You created an object like normal, but the underlying platform would create the actual object on a remote machine. You’d call functions on your local proxy and the platform would marshal the call across the network to the real object. The network hop would still be there, but the platform abstracted away the mechanics of making it. Examples of distributed object platforms include CORBA via IOR, Java RMI, COM via DCOM and .NET Remoting.

The (now well documented and understood) problem with this approach is that distributed objects can’t be designed like other objects. For performance reasons, distributed objects have to have what Martin Fowler called a “coarse-grained interface”, a design which sacrifices flexibility and extensibility in return for minimizing the number of cross-network calls. Because the network overhead can’t be abstracted away, distributed objects are a very leaky abstraction.

So in 2003, Indigo folks came along and basically said “You know the distributed object paradigm? The one we’ve been shipping in our platform since 1996? Yeah, turns out we think that’s the wrong approach.” Go back and check out this interview with Don Box from early 2004. The interviewer asks Don if WCF will “declare the death of distributed objects”. Don hems and haws at first, saying “that’s probably too strong of a statement” but then later says that the “contract, protocol, messaging oriented style will win out” over distributed objects because of natural selection.

The tenets, IMHO, were really designed to help the Windows developer community wrap their heads around some of the implications of messaging and service orientation. These ideas weren’t really new – the four tenets apply to EDI, which has been around for decades. But for a generation of Windows developers who had cut their teeth on DCOM, MTS and VB, it was a significant paradigm shift.

These days, with the tenets going on four years old, the conversation has shifted. Platform vendors are falling over themselves to ship service/messaging stacks like WCF and most developers are looking to these stacks for the next systems they build. Did the tenets do that? In part, I think. Mainstream adoption of RSS was probably the single biggest driver of this paradigm shift, but the tenets certainly helped. Either way, now that service orientation is mainstream, I would say that the tenets’ job is done and it’s time to retire them. Once you accept the service-oriented paradigm, what further guidance do the tenets provide? Not much, if any.

I thought of another approach to the InitImportantThing problem that I blogged about yesterday. I think it’s a bit harder to code, but it’s certainly explicit and avoids the magic method that Jon dislikes so much.

The crux of the problem is that ServiceHostBase needs a valid ServiceDescription in order to operate. The WCF team chose to provide said description to ServiceHostBase via the abstract CreateDescription method. But as we saw, ServiceHostBase can’t call CreateDescription from it’s own constructor. So instead, derived classes are forced to call InitializeDescription in their own constructor. Since that call isn’t enforced by the compiler, it’s easy to forget to include it. Since the exception that gets thrown doesn’t really tell you what went wrong, it’s easy to spend hours trying to figure it out.

So here’s a better approach: since the ServiceHostBase needs a valid ServiceDescription in order to operate, why not pass it in as a constructor parameter?

ServiceHostBase has a protected constructor with no parameters. But since it needs you to call InitializeDescription in your derived class constructor, it really needs the ServiceDescription, a collection of ContractDescriptions (also returned from CreateDescription) and a collection of base addresses (passed into InitalizeDescription). If these were parameters on ServiceHostBase’s constructor, it could validate that information directly, without needing abstract or magic methods.

The one problem with this approach is that the creation of a ServiceDescription is non-trivial. ServiceHost’s implementation of CreateDescription generates the ServiceDescription by reflecting over the service type. You still need that code, but now you would call it from the base constructor initializer instead. That means it has to be a static method, but otherwise it would work just fine. Here’s yesterday’s code, updated for this approach:

public abstract class Base
{
    public Base(string importantThing)
    {
        if (string.IsNullOrEmpty(importantThing))
            throw new Exception();

        _importantThing = importantThing;

    }

    private string _importantThing;

    public string ImportantThing  
    {  
        get { return _importantThing; }  
    }
}

public class Derived : Base
{
    private object _data;

    public Derived(DateTime dt) : base(CreateImportantThing(dt))
    {
        _data = dt;
    }

    private static string CreateImportantThing(DateTime dt)
    {
        //this is obviously trivial, but could be much
        //more complicated if need be
        return dt.ToLongDateString();
    }
}

This seems like the best approach to me. You remove the un-obvious magic method call requirement when deriving your own service host while still enforcing the data consistency check in the base class during construction. Best of both worlds, right?

So I wonder why the WCF team didn’t do it this way?

• My two sessions on Rome went very well. Sort of like what I did @ TechEd last month, but with a bit more kimono opening since it was an internal audience. Best things about doing these types of talks is the questions and post-session conversation. I’ve missed that since moving over to MSIT.
• Late last week, I got my phone switched over to the new Office Communications Server 2007 beta. In my old office, I used the Office Communicator PBX phone integration features extensively. However, when we moved we got new IP phones that didn’t integrate with Communicator. So when a chance to get on the beta came along, I jumped. I’ll let you know my impressions after a few weeks, in the meantime you can read about Mark Deakin’s experience.
• Matevz Gacnik figures out how to build a transactional web service that interacts with the new transactional file system in Vista and Server 08. Interesting, but personally I don’t believe in using transactional web services. The whole point of service orientation is to reduce the coupling between services. Trying two services (technically, a service consumer and provider) together in an atomic transaction seems like going in the wrong direction. Still, good on Matevz for digging into the transactional file system.
• Udi Dahan gives us 6 simple steps to being a “top” IT consultant. I notice that getting well known, speaking and publishing are at the top of the list but actually being good at what you’re well known for comes in at #5 on the list. I’m sure Udi thinks that’s implicit in becoming a “top” consultant, but I’m not so sure.
• Pat Helland thinks Normalization is for Sissies. Slide #6 has the key take away: “For God’s Sake, Don’t Normalize Immutable Data”.
• Larry O’Brien bashes the new binary efficient XML working group and working draft. I agree 100% w/ Larry. These aren’t the droids we’re looking for.
• John Evdemon points to a new e-book from my old team called SOA in the Real World. I flipped thru it (figuratively) and it appears to drill into the Foundations of Solution Architecture as well as provide real-world case studdies for each of the pillars recurring logical capabilities. Need to give it a deeper read.

Seems like a slow week.

• Jules and I went to see the latest Harry Potter movie this past weekend. It’s easily the weakest of the six HP stories so far. The first two stories were about discovering this magical world, the next two about discovering Harry’s past, and the last two about confronting said past. That leaves OotP as the odd-story-out, mostly bridging from the end of the fourth story to the start of the sixth.
• Speaking of movies, the new movie feature of Mobile Search v2 rocks, though I have two quick suggestions. First, it would be nice to have a time-sorted view of when a given movie is playing. So if it’s playing at 4pm at one theater and 4:30pm at another, you’d see them in a list ordered that way. Second, how about an option to buy tickets directly from the phone?
• If you’re interested in WPF and 3D, Eric Sink has a series for you.
• Old news, but Windows Home Server RTMed on Monday. I’m really looking forward to this product.
• I was looking for some information on how WCF pumps messages in the service host and I found this post from Maheshwar Jayaraman. Between that post and Reflector, I think I’ve got a good handle on how ChannelDispatcher works.
• Larry O’Brein callsoutthree MS Research Projects. Microsoft Research Accelerator is a high-level data-parallel library that targets GPUs. Graph Layout Execution Engine (aka GLEE) is a library for graph layout and viewing. VirtualEarth MapCruncher converts existing maps (PDF and bitmaps) to work with Virtual Earth.
• Ted Neward weighs in on the David Chappell’s Korean War REST vs. WS-* analogy. Skim the history lesson, but make sure you read his points about security and reliability interop. WS-* has addressed these areas, so if you need those capabilities, why wouldn’t you use WS-* to get them rather than re-invent the wheel? As for the history lesson, Ted does say he thinks software development is more analogous to making war than building a house. He expands on that idea and recommends Robert Greene’s The 33 Strategies of War. I want to read the book and mull it over a bit, but I certainly see where Ted’s coming from.