Morning Coffee 121

• My daughter had her tonsils & adenoids out on yesterday. It was a routine procedure and it went by-the-numbers, but any parent will tell you it's hard to see your kid in a hospital bed.
• Given the previous bullet, I'm not at the SOA/BPM conference for the big announcement. Don't worry, there's lots of other folks covering the news.
• It was a crappy sports weekend in the Pierson house. Va Tech snatched defeat from the jaws of victory, Southern Cal never led at Oregon, the Capitals lost twice, and the Redskins got blown out by the Pats. At least the Caps won big yesterday in Toronto.
• Speaking of the Capitals, Peter Bondra retired Monday. I still think it's a travesty that he didn't spend his whole career in DC, but I've made my peace with it.
• Nick Malik has a great series on business operations models and how they apply to SOA. Regular readers should be unsurprised that I favor low standardization, though I can see the value of high integration. That makes the Coordinated Operating Model my fav, though I can see the benefit of the Diversified Model as well. I can't wait to read what Nick has to say on changing models.
• Speaking of Nick, I'm doing a roundtable with him on "Making SOA Work in the Enterprise" @ the Strategic Architect Forum. Should be fun. Sorry for the lack of linkage on this, but it's an invite-only event.
• Jezz Santos has a new series of white papers on building software factories. First up "Packaging with Visual Studio 2005"
• Aaron Skonnard has a new whitepaper on using the WCF LOB Adapter SDK with BTS 2006 R2. I've been building one of these things recently, so I'm looking forward to checking that out. (via Sam Gentile)
• Tim Ewald looks at Resource Oriented Architecture (when did ROA become a TLA?) and wonders "what if your problem domain is more focused on processes than data?" I wonder that all the time. (via Jesus Rodriguez)
• It's not just durable messaging - Libor Soucek also disagrees with my opinions on centralized control. I agree 100% with Libor that centralized management would make operation's lives "much, MUCH easier" as he puts it. However, that doesn't make it feasible at any significant scale. Furthermore, I wouldn't describe an approach that requires that "all services adopt [the] same common management interface" as "pragmatic". Frankly, just the opposite.

Morning Coffee 117

• Quick update to the DevHawk 2007 World Tour: I won't be making it to the SOA & BP Conference. Riley's having her tonsils out. As much as I'd like to hang with my geek peeps, family is the priority. But I can still make an evening event or geek dinner later in the week if anyone is game.
• Caps season-opening winning streak continues. Still 100% on the PK, though the power play is pretty anemic. As I said yesterday, it's WAAAAY to early in the season to start bragging, but starting strong is much better than starting weak.
• Speaking of hockey, looks like the NHL Network is launching in the US this month (it's been available in Canada since 2001). Also, NHL.tv is up and running. Those wishing to see Caps highlights can go directly to Capitals.NHL.tv. Unfortunately, if you want to see full games, you've got to subscribe to Center Ice or Center Ice Online to the tune of $150. But I don't want to get "up to 40 games each week", I just want the Caps games. Between the time zone difference and kids, it's not like I have time to watch that much hockey anyway. Why can't I subscribe to just the Caps games online for say $25 a season?
• Finished Halo 3 Sunday night. Fun game and a great end of the trilogy. Looking forward to what the newly-independent Bungie does next. Something tells me we haven't seen the last of Master Chief. However, I do think Bioshock has better and more original storytelling. Mass Effect looks like it'll be better still.
• Sam Gentile pointed out that his Neudesic colleague David Pallmann has posted a series of WCF tips. Several of them are right on the money like "Take Advantage of One Way Operations" and "Use a Discovery Mechanism to Locate Services". However, I can't agree with "Maintain a Service Catalog". David warns that if you don't, "The left hand won’t know what the right hand is doing." Of course, that's probably the case regardless of how you maintain your service catalog. And "Retry on minor failures"? That's fine, if you've got an idempotent operation. Unfortunately, most non-read operations aren't idempotent unless you take the time to design them that way. And most people don't.
• Speaking of Sam, he's blown up his CodeBetter blog and walked away from the ALT.NET crowd. I've not been a fan of this ALT.NET stuff since it surfaced - as Sam said, "ALT.NET is a divisive thing" - so I'm happy to see my good friend walk away from it.
• Speaking of ALT.NET, Scott Hanselman blogged about previewing the new ASP.NET MVC Framework at the ALT.NET conference. Like Sam, Scott thinks the term ALT.NET is "too polarizing". I like Scott's suggestion for Pragmatic.NET. Oh, and the MVC framework stuff looks cool too.
• Reading Dare's description of OAuth gave me a distinct sensation of deja-vu.

Durable Services with Fake Persistence

I've been investigating the new WCF/WF integration in .NET Framework 3.5. I want to understand how the new context features work. Unfortunately, there's not much info out there (that I could find at any rate). You're pretty much stuck with the samples and Jesus Rodriguez's overview of durable services. So I sat down to dig a little deeper.

Note, since there are no docs on this stuff as I write this, many of the links below are Reflector code links.

I started by lifting the DurableCalculator sample contract and service implementation and dumping it into a new WCF Service Library project. I did this for two reasons. First, VS08 has added a WCF Service Host much like VS05 added the ASP.NET Development Server. Very cool. But the existing sample is still written to be hosted in IIS, so I wanted to change that. Second, and much more important, I wanted to start with a vanilla config file. I knew it wouldn't work out of the box, but the point of this exercise was to learn how this works under the covers.

When you fire up the durable service with the vanilla config file, you get an error (as expected). Services marked with the DurableServiceAttribute require a binding that supports the context protocol. WsHttpBinding, the default binding when you create a new service, doesn't. However, it's easy to fix by switching to wsHttpContextBinding instead. Via Reflector, we see that wsHttpContextBinding inherits from wsHttpBinding and adds a ContextBindingElement to the binding element collection created by the base class. BasicHttpContextBinding and netTcpContextBinding work the same way.

Even after changing to wsHttpContextBinding, we're still getting an error on service start. But it's a new error, so we're making progress. Now, we're told that services marked with DurableServiceAttribute need a persistence provider to be specified. If we look in the original sample's web.config file, we find a persistenceProvider element in the service behavior. This element references the SqlPersistenceProviderFactory type. Obviously, the point here is to persist durable service instances to the database between calls, much as WF can do.

However, merely configuring the existing SQL persistence provider doesn't really tell you what's going on under the hood. Besides, often when you're experimenting, you don't really want to go thru the headache of setting up a SQL store for persisting instances to. Somewhere along the line, I implemented a fake persistence service for WF that stored the serialized instances in memory. So I decided to do the same for WCF durable services.

Building a WCF Persistence Provider requires building two classes: a factory and the provider itself. Factories inherit from PersistenceProviderFactory, which exposes only one non-CommunicationObject method: CreateProvider. It appears that the service host creates a single persistence provider factory and calls CreateProvider whenever it needs a persistence provider. Providers themselves inherit from PersistenceProvider, which exposes methods to Load, Save and Delete durable service instances.

My FakePersistenceProvider (and factory) are brain dead simple, though the ratio of "real" code to factory and CommunicationObject scaffolding is quite low (about 40 lines out of 258). The factory keeps a dictionary of serialized service instances, keyed by guid. When providers are created, this key guid is passed as a parameter to CreateProvider. The provider instances delegate Load, Save and Delete back to internal methods on the factory class. The methods themselves use the NetDataContractSerializer to serialize the service instance out to a byte array and deserializing it back again. I chose NetDataContractSerializer because that's what the SQL persistence provider uses under the hood.

PersistenceProvider supports async versions of Load, Save and Delete but I didn't implement them. Also, there's a LockingPersistenceProvider abstract class which adds (you guessed it) instance locking semantics. However, my fake provider doesn't span machines, much less require locking semantics so I skipped it.

So it looks like DurableServiceAttribute, context-supporting bindings and persistence providers are all inter-related. Certainly, you can't use the attribute with out the binding and persistence provider. As I continue to dig, I'm want to see how context inter-relates with WF as well as it's possible usage outside of DurableServiceAttribute based scenarios.

If you're interested in the code, I've stuck it up on my SkyDrive. In addition to the FakePersistenceProvider implementation and the simple Durable Calculator service, it includes a simple client to test the service and persistence provider. The WCF Service Host includes a test client, but it doesn't appear to support the context protocol, so I had to build a simple test app instead. Enjoy.

Morning Coffee 113

• I'm in Chicago today and tomorrow for a reunion of sorts. In my last job, I managed a group of external architects called the Microsoft Architecture Advisory Board (aka the MAAB). We discontinued the program a while back, but the core of the group found the program valuable enough they have continued to meet anyway. I found the MAAB meetings incredibly valuable and insightful, so I'm really excited to be invited to continue my involvement with the group.
• I picked up Bioshock Tuesday (Circuit City had it on sale) on my way to my bi-weekly campus excursion. My meetings were over around 2pm so I headed home early, expecting to surprise the kids. But Jules had decided to skip naps and go shopping with them. Her cell phone was dead, so I ended up at home with a couple of hours to myself and a brand new copy of Bioshock. Wow, is that a good game. Certainly deserving of the amazingly good reviews it's garnered.
• Speaking of reviews, this transparently biased review of Bioshock over at Sony Defense Farce Force is frakking hilarious. Somehow, I doubt their dubious review will stem the tidal wave of Bioshock's well-deserved hype. Can't wait to read their Halo 3 review.
• Pat Helland writes at length on master-master replication. I reformated it into PDF so I could read it - the large images were messing up the text flow on my system. As usual for Pat, there's gold in that thar post. His thoughts on DAGs of versions and vector clocks as identifiers are very exciting. However, I think he glosses over the importance of declarative merging. I would think programmatic merge would likely be non-deterministic across nodes. If so, wouldn't you end up with two documents with the same vector-clock identifier by different data?
• Joe McKendrick points to a few people who predict the term "service-oriented" will eventually be subsumed under the general heading of "architecture". Not to brag, but I made that exact same prediction almost three years ago.
• Erik Johnson thinks that SOA 2.0 centers on transformational patterns. The idea (I think) is that if systems "understand each other more deeply", then we can build a "smarter stack" and design apps via new constructs to promote agility and simplicity. Personally, I'm skeptical that we can define unambiguously system semantics except in the simplest scenarios, but Erik talks about using "graph transformation mathematics" to encode semantics. I don't know anything about graph transformation mathematics, but at least Erik has progressed beyond hand waving to describing the "what". Here's looking forward to the "how".
• New dad Clemens Vasters somehow finds time to implement an XML-RPC binding for WCF 3.5. I was encouraged that it didn't require any custom attributes or extensions at the programmer level. Of course, XML-RPC fits semantically into WCF's interface based service model, so it shouldn't be a huge surprise that it didn't require any custom extensions. But did it need WCF 3.5? Would this work if recompiled against the 3.0 assemblies?
• Phil Haack writes a long post on Duck Typing. VB9 originally supported duck typing - the feature was called Dynamic Interfaces - when it was first announced, but it was subsequently cut. I was really looking forward to that feature. Between it and XML Literals, VB9 was really stepping out of C#'s shadow. I guess it still is, even without dynamic interfaces.
• Since I've been doing some LINQ to XML work lately, I decided to go back and re-write my code in VB9 using XML literals. While XML literals are nice, I don't think they're a must have. First, LINQ to XML has a nice fluent interface, so the literals don't give you that much cleaner code (though you do avoid writing XElement and XAttribute over and over.) Second, I find VB9's template syntax (like ASP <%= expression %>) clunky to work with, especially in nested templates. Finally, I like the namespace support of XNames better. As far as I can tell, VB9 defines namespaces with xmlns attributes just like XML does. So I'm not dying for literal XML support in a future version of C#. How about you?

Morning Coffee 111

• I'm not sure if I should laugh or cry at Nick Malik's definition of politecture. I mean, it's funny so I'm laughing, but it's so true that it makes me want to cry.
• Don Box comments on retiring the tenets. It's good to see him say "please God tell me we can do better" than CLR interfaces or WSDL.
• Looks like the P2P APIs are finally getting the managed treatment in .NET FX 3.5. A long time ago, John deVadoss asked me what an enterprise system like CRM might look like if it used a peer-to-peer approach instead of client-server. If I had any free time, I'd prototype one out on this API. (via Mike Taulty)
• Scott Guthrie goes back to his LINQ to SQL series to tackle Stored Procs and UDFs. Being able to use UDFs inline with LINQ queries is very cool. However, it seems to me that LINQ discourages the use of stored procs. As a developer, I'd rather write LINQ queries than stored procs, if I can. The probably puts me at odds with DBAs who'd rather all DB access be via stored procs they control.
• Soma writes about new MSBuild enhancements in VS08: multi-targeting and parallel build.
• I just discovered Vista Battery Saver. Basically, it turns off Aero and Sidebar when you're on battery. I'm traveling to Chicago next week, so we'll see if it has much impact on my battery life. (via Plenty of Code and Larkware)

Morning Coffee 110

• 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.

Retire the Tenets

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? [1]

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.

[1] Not that you would catch me drinking Miller Lite. Ever.

Another InitImportantThing Approach

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:

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? 

Early Afternoon Coffee 105

• 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.

Morning Coffee 102

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 calls out three 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.

Morning Coffee 91

• My wife loves me. I'm a very lucky man.
• I'm starting to really dig Safari Books Online. Having a tablet really helps here, I can sit in bed and read and it's ALMOST like reading a real book. Is there an offline experience? Something like the NYTimes WPF Reader app would be killer.
• I'm not a Twitter guy, but I like the idea of using it to publish CI results. Not quite as cool as using the Ambient Orb, but close. (via DotNetKicks)
• Soma details the dogfood usage of TFS in Developer Division. Sorta interesting if you're into knowing that stuff. Brian Harry apparently has much more.
• I realize that linking to Pat Helland every time he writes something is fairly redundant. If you want his feed, you know where to find it. But he writes great stuff! The latest is Accountants Don't Use Erasers, which talks about append-only computing. His point that the database is a cache of the transaction log is mind blowing, yet makes total sense.
• Bruce Payette blogs a PS DSL for creating XML documents.
• Jesus Rodriguez details WCF's new Durable Service support in .NET 3.5. I get the need for the [DurableServiceBehavior] attribute, but do I really have to adorn each of the service methods with [DurableOperationBehavior] too? That seems redundant. Also, I wonder how this looks at the channel layer?
• Speaking of WCF's channel layer, I recently picked up a copy of Inside Windows Communication Foundation by Justin Smith. This is the first book I've found that has more coverage of the channel layer than the service layer, so I like it.
• Dare writes about Web3S, Windows Live's general purpose REST protocol. Apparently, WL started with Atom Publishing Protocol, but found that it didn't meet their needs around hierarchy and granular updates. David Ing says it's "not that similar" to my concept of REST, but I going to read the spec before I comment.
• Scott Hanselman writes about how he learned to program and some thoughts about teaching his son. Patrick has recently started expressing interest in programming (he want's to do what Daddy does). At four, I'm thinking I'll start him on Scratch (though ToonTalk looks interesting). As he gets older, I was thinking about Squeak, though I'm a smalltalk noob. I really like Scott's idea of creating a connection to the physical world via something like Mindstorms. Patrick loves Lego almost as much as his dad, so that would be cool.

Morning Coffee 75

• 3D Printing is going to be huge. According to the NYT, we'll be looking at around $1,000 for one within four years. For the impatient, check out Fab@Home and build one right now.
• It's been a while since I experimented with the P2P stack in Windows, but it looks like it's getting the managed treatment in VS "Orcas".
• The managed Ruby hits keep on coming. Last week was DLR and IronRuby. This week it's a new drop of Ruby.NET which includes VS integration.
• Looks like Sun is trying to get back into the Ajax/Flash/Silverlight fray with JavaFX Script. I wrote over a year ago that "In platform portability, Flash has succeeded where Java failed." I can't help but believe JavaFX is too little too late. Also, it's yet another Java technology name that sounds like it's been blatantly copied from MSFT. JDBC, JSP, JDO ... What's next? JINQ? (via TechMeme)
• Steve Maine has a great series of posts on the new Web Programming Model that's coming in .NET 3.5 and is currently being previewed as part of the BizTalk Services SDK. But it was his Balancing reach and rich post that I found most illuminating. The first version of WCF feels hopelessly bound to the WS-* view of the world, which makes it difficult to incorporate alternative messaging models into the same programming model. I've run into this trying to use SSB with WCF. In the next version, that WCF / WS-* marriage looks like it's getting a little more open. In my current role, I'm not so interested in the web programming model, but I am very interested in how they are integrating these alternative models.

Morning Coffee 58

• Nicholas Allen points out that Messaging is not a Transaction. Of course, what he really means is that Messaging with WCF is not a Transaction. Messaging with SSB is in fact a transaction (well, more accurately, it's transactional but you get the idea). Nick's right that you may not need anything more than simple retry semantics that you can implement yourself in your application protocol. But SSB has spoiled me. Why should I have to write the retry semantics? Why can't my messaging stack provide that for me? Or put another way, if I need a "precicely defined failure model", wouldn't I be better of choosing a messaging stack that provides that out of the box?
• Steve Hartman explains how to use span Remote Desktop Connection across multiple monitors for use with VPC. I wonder if this will work on my machine, since my multi-monitor setup is an L shape, not a rectangle. I'm offsite today, so I'll try it tomorrow (via DotNetKicks)
• According to news reports, Microsoft is negotiating to provide DRM free music too. I wonder how well this will work for Microsoft given that both Zune and PlaysForSure provide subscription services. I would assume the $15 all-you-can-listen style subscription services wouldn't be DRM free. Given that program is one of the (few) selling points they have over Apple, will the availablity of DRM Free music undercut the interest in subscription? (via Dale)

Answering Dr. Nick's Questions on SSB & WCF

Nick Allen asked on his blog about how people would like to see SSB and WCF work together. He's already heard these from me, but I figured I'd put them out there for everyone to see and debate. Plus, I had several beers last night at the MVP dinner, so this is likely to be more coherent than I was yesterday! :)

1. Are you interested in SSB because you'd like to have your service closer to the database? How close is close enough to the database?

I've first blogged about the endangered middle tier almost three years ago. My point at the time was that as you break your monolithic system up into services, the vast majority of those services won't need to scale out. You performance gets better the closer you are to the data. If you don't need to scale out, why not get the maximum boost by running in the database process itself?

Furthermore, in large IT shops, the database files are stored out on the SAN rather than on hard drives attached to the database server itself. That means the database server is effectively stateless. Why add a second stateless tier if you don't need scale out? If you need more performance in a given service, you can detach the database file from it's current SQL server box and attach it on another more beefy SQL server box without physically moving the database files at all. This enables what I call the "Star Trek Effect", where you can shift computing power where it is needed most (more power to the payroll system!).

Of course, if you're going to move the service, you do need to bring it down for a short time. That implies a need for durable messaging so that service consumers aren't affected by the brief service interruption. Which brings us to...

2. Are you interested in SSB because you need durable, duplex messaging between two services? Do you need exactly-once-in-order message delivery?

Yes. SSB has a bunch of other nice features, but durable duplex messaging is what I need the most. Exactly-once-in-order is also fairly critical, though there may be scenarios where it's not really necessary. Those are the exception, not the rule however.

Doesn't WS-RM already do EOIO already?

3. Are you interested in using SSB from WCF because you want a better asynchronous messaging experience than MSMQ? What makes you prefer SSB to other queuing products?

My primary problem with MSMQ for the problems I'm tasked with solving is that MSMQ is one way while SSB supports duplex messaging. You could do duplex messaging with MSMQ if you didn't mind managing multiple queues (one for each side of the conversation) but SSB does this for you for free. I'm sure there are scenarios where pure one-way messaging are useful, but they are few and far between in my day job.

Furthermore, SSB has the explicit idea of a service instance (they call it a conversation group) which MSMQ lacks. SSB's implementation is conceptually similar to the new WCF/WF integration work in the latest Orcas CTP.

Finally, SSB uses logical naming. You have conversations between services, but services get mapped to physical addresses at the routing layer. This allows services to move around more easily (see the "Star Trek Effect" in #1 above). Both MSMQ and WCF use physical addresses, which makes them much more difficult to move.

4. Are you interested in having your data contracts defined in WCF, SQL, or both?

I like WCF's data contract infrastructure. We did a early prototype long-running service with both WCF and SSB. the messaging stack code was obviously different, but we used the exact same data contract code. I even wrote some code to automatically deserialize the SSB message by mapping the SSB message type to a data contract.

I want my services to run inside the database, but that doesn't mean I want to write them in T-SQL. Personally, I'm much more productive in C# and/or WF. So WCF data contracts are fine by me.

Morning Coffee 45

• Yesterday's morning coffee was canceled on account of going to main campus and hanging out with the Architect MVPs. I spent all morning + dinner with them yesterday. Some of these guys I hadn't seen in nearly two years, so it was a ton of fun.
• Nicolas Allen (aka Dr. Nick) is looking for SQL Service Broker users. I cornered him at the MVP dinner last night and gave him my thoughts on WCF + SSB. You can head over to his blog and do the same. (I'll post my answers to his questions later today, hopefully)
• The new Vista x64 driver for my workstation's video card does support monior rotation, so I'm mostly XP free at this point. I'm dual-booting my workstation at this point, while I finish configuring stuff in the Vista partition. With both my workstation and work laptop tablet, I'm XP free at work. Next, I start getting home machines moved over.
• Tom Hollander reports on a new drop of the Guidance Automation Toolkit. Mostly bug fixes like Vista support, but the full list is here. It's an ugly upgrade process. You have to uninstall all existing guidance packages. I can't wait until this technology is "integrate[d] ... more deeply into Visual Studio and Team System".
• I mentioned the Podcast Authoring tool that I saw at TechFest last week. Here are some pictures of it from engadget (via Loke Uei Tan)
• I've been thinking of getting a Wii, and the fact I can hack code for it - managed code for managed snobs no less - is just another good reason to do it. (via DotNetKicks)

Morning Coffee 40

• My boss let me borrow a Tecra M4 that he scavenged from his boss. The display is fairly twitchy, I think it's a motherboard issue. But it's very intermittent and I'll get help desk to take a look. In the meantime, it sure is nice to driving a Tablet PC again. And it's Vista ready to boot.
• Speaking of Vista, Visual Studio 2005 Service Pack 1 Update for Windows Vista. It's a mouthful but it's now available. Soma answers questions about the new release on MS PressPass.
• The DSL tools team keeps on rolling with the power toys. First it was the Designer Integration PowerToy, now it's the DSL Tree Grid Editor PowerToy. Jeff Santos has the details.
• I missed the TechFest keynote yesterday, but it's available on demand. They also have descriptions and videos of some of the technologies on display. (well, only one video so far, but I assume since the page is labeled "TechFest 2007 Videos" that more are on the way.)
• There's new support for integrating WCF and WF coming in VS "Orcas". Moustafa Khalil Ahmed has the details on what's new for WF & WCF in the latest CTP drop. For me personally, the WCF/WF integration is some of the most important stuff coming in Orcas, second only to LINQ.

Morning Doughnuts 4

• According to Reuters surgeons who play video games are more skilled. Remind me to ask the doctor if s/he owns an XBOX 360 the next time I am getting operated on.
• I have reached the National Championship game in dynasty mode of NCAA Football 2007. The opponent of my BYU Cougars...why that would be Harry's alma mater, the USC Trojans. Funny how that worked out.
• Nicholas Allen writes in his blog about when you should use Indigo to write a channel, and more importantly when you should not. As most of you know Harry and I are doing quite a bit of work with WCF so we are interested in this type of advice.
• Our team has been thinking about how to manage a large number of services in an automated fashion. This would include deploying new services, monitoring the services, automatically handling scaling, service discovery, and automated provisioning to name a few possible capabilities. I almost think of it like the next version of UDDI, especially when it comes to provisioning. I think that as systems become more distributed that the ability to automatically manage these systems is going to be key to their success. I know that some thought has already gone on in this area by people far smarter than I, but as I consider how to operate an infrastructure with thousands of services in it it is apparent that the opportunity is there for us to design and implement a system management framework that automates the majority of the tasks. I need to spend some time to consider how the framework would work, and document the capabilities.

Reliably Beating a Dead Horse

(Harry is on a secret mission in uncharted space this week, so instead of the daily Morning Coffee post, you get a series of autoposted essays. This post builds on Harry's recent epiphany about WCF and long running services)

Way, way, way back in March of 2003, IBM and Microsoft published an "overview and roadmap" white paper entitled "Reliable Message Delivery in a Web Services World". It contained the following paragraph under the section "Exchanging Messages Reliably":

WS-ReliableMessaging is not bound to underlying transport protocols or sessions. This means that the lifetime of a WS-ReliableMessaging conversation can span long periods of time (days, weeks) even when one or both systems are rebooted. This allows conversations to be suspended mid-stream (for example, to allow system maintenance) and then resumed without needing to retransmit the entire conversation. [emphasis added]

Now I know how I got confused about WCF and long running services in the first place. Support for long running services was part of the original web services vision!

About three years after that white paper was published, Shy Cohen wrote a post entitled Reliable Messaging Demystified on his blog. Shy was at one time the feature owner of WS-RM in WCF (according to his post) and wrote the following:

Reliable sessions [in WCF] are implemented using the WS-ReliableMessaging protocol. This protocol is yet another misnamed WS-* protocol, as it actually only deals with the reliability of the transfer and says nothing about durability, delivery acknowledgments, TTL for a message, long running sessions where a particular message is lost forever, etc.

At some point in the three years between March 2003 and February 2006, WS-RM went from being the enabler of long running services to "yet another misnamed WS-* protocol". And with it, WCF lost (never had?) the ability to support long running services (as I've written previously).

Now all and all, this isn't a big deal. I agree with Shy that WS-RM is under specified as mechanism for durable messaging (Shy calls this "queued messaging"). Attempting to build durable messaging on top of WS-RM sounds like it would have been both difficult and unlike to broadly interoperate. So implementing WS-RM for TCP style reliability and leveraging MSMQ as a transport for people that need durable messaging sounds like a pretty good compromise, especially for a v1 product. Of course, it is not exactly unheard of for a project's end result not to completely live up to the original vision. But I have a specific requirements in this case, so I wanted to know more.

By calling it "misnamed", it sounds like WS-RM was never really intended to be used for durable messaging. However, the July 2003 Reliable Messaging Feedback Workshop indicates that it was. In particular, Rodney Limprecht's "Reliable Messaging Scenarios" deck describes WS-RM as supporting scenarios requiring "either volatile or durable endpoint state". His list of scenarios included both an "Intermittent Connectivity" scenario where "messages pending transfer are staged to disk and exchanged when connected" as well as a "Message Queue Integration" scenario that used WS-RM to interop between JMS and MSMQ. Seems safe to say that WS-RM was originally intended to support durable messaging. So what happened? How did it become "misnamed"?

Rodney's deck describes WS-RM as having the "flexibility to meet scenario requirements". But flexibility comes at a cost. For example, the flexibility of WCF's configuration comes at the cost of significant complexity. In the case of WS-RM, it appears that by trying to make it flexible enough to support both volatile and durable reliability, the authors might have made it too flexible. WS-RM implementers have broad latitude in building the capabilities Shy mentions (durability, acknowledgements, TTL, etc) as well as describing said capabilities in policy. By providing that latitude, we lost the ability to broadly interop durable messaging, which I would suspect is why it ended up out of scope for WCF v1.

As I said before, lack of support for WS-RM based durable messaging isn't that big a deal. As long as you understand WCF's sweet spot - the current version's sweet spot anyway - and don't try and make it be something it's not, you should be fine. Furthermore, Shy mentions the need for an "interoperable Queued Messaging specification" and wrote that it's something he "expect[s] that we will get to it in the near future". Here's hoping that spec is less flexible than WS-ReliableMessaging.