Brad Wilson and Scott Hanselman took me to task for my comment the other day that no “mainstream” language had implemented extension methods:

How mainstream is Ruby on Rails for you? Ruby is a full fledged dynamic language. No hacks for “extension methods” (Brad)

Ya, I kind of blanched at that statement too…method_missing is pretty mainstream… (Scott)

They’re right, Ruby does support the addition (and redefinition I think) of methods on a class at any time. There’s a sample of this in the Classes and Objects chapter of Programming Ruby (aka the pick-axe book) where they add a basic documentation facility “available to any module or class” in Ruby by adding a doc instance method to the Module class.

class Module
  @@docs = Hash.new(nil)
  def doc(str)
    @@docs[self.name] = str
  end
  def Module::doc(aClass)
    # If we’re passed a class or module, convert to string
    # (‘<=’ for classes checks for same class or subtype)
    aClass = aClass.name if aClass.type <= Module
    @@docs[aClass] || “No documentation for #{aClass}”
  end
end

Given how Ruby classes are defined, I think the newly added methods have access to the private data of the class. Extension methods in C#3/VB9 only have access the public interface of the object. But that’s a fairly minor difference.

FYI, Powershell can do this as well, though not as succinctly as Ruby. Scott has an example how you can add a DatePhotoTaken property to System.IO.FileInfo using Omar Shahine’sPhotoLibrary project.

Chalk this up to my continuing ignorance of dynamic languages. I’m working on it, albeit slowly.

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.

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