I’ll be honest, I recommended Herb Sutter’s concurrency series in today’s Morning Coffee because it a series on concurrency by Herb Sutter. In other words, I hadn’t actually read it yet, but I know how good Sutter’s stuff is. Now I have read it and I wanted to re-issue my recommendation, even more strongly. Go read it.

Interestingly enough, I like the article because it doesn’t provide an “answer” to the problem of concurrency. Rather, by providing a mental model, it essentially is a concise and precise restatement of the problem. Often, in the rush to find a solution to a problem, this step is skipped and it isn’t until the end that you realize that you misunderstood the original problem and what you built doesn’t match what you need.

I’ve often argued that this is also the key to selling in the enterprise. In my experience, whatever solution you’re selling is usually way too complicated to be understood by the people who have the purchasing power to buy it. So explaining how your solution works or how your solution solves the problem isn’t going to get you very far. However, the buyer does understand the problem at hand. Being able to demonstrate that you understand the fundamental nature of the problem and can communicate it back to them garners you a great deal of trust in the selling process. If you can show that you understand their problem, then you probably know how to fix it – even if the buyer doesn’t understand how your solution works.

One other quick thought on Sutter’s article. In discussing the use of concurrency to keep a GUI responsive (aka Pillar 1), he wrote the following:

Today, we typically express Pillar 1 by running the background work on its own thread or as a work item on a thread pool; the foreground task that wants to stay responsive is typically long-running and is usually a thread; and communication happens through message queues and message-like abstractions like futures (Java Future, .NET IAsyncResult). In coming years, we’ll get new tools and abstractions in this pillar, where potential candidates include active objects/services (objects that conceptually run on their own thread, and calling a method is an asynchronous message); channels of communication between two or more tasks; and contracts that let us explicitly express, enforce, and validate the expected order of messages. [emphasis added]

If we’re going to provide the ability to express, enforce and validate the expected order of messages between concurrent blocks of code, can we also do it for services across the network? WSDL is wholly deficient in this area. SSDL’s Communicating Sequential Processes (CSP) and Rules-based Protocol Frameworks are a good start.

Normally, I would simply note that Nick Malik had finally moved on from the Great Mort vs. Agile Debate^tm in my next Morning Coffee post and be done with it. But man, his post on the Unimportant SOA Catalog is just too good to leave until then…

Nick has come around to the view that the catalog does “a really good job of solving the wrong problem”. I agree 100%. I haven’t talked about it much here, but my teammates could tell you I have been on a rampage about this internally. People think a service catalog will create adoption and reuse. That suggests that the big obstacle to service adoption and reuse is simply the issue of finding something to adopt or reuse.

It’s not.

The next PM I meet who says “I wish I had a big catalog of services so I can search for something that I can take an external dependency on” will be the first. And they’ll probably be wearing a straightjacket, because looking for dependencies on purpose like that is crazy talk. Project managers avoidexternal dependencies like the plague. So when a PM looks at a service catalog, what they see a big list of stuff they don’t want to take a dependency on. Not exactly the mindset to stimulate reuse and adoption, is it?

Nick suggests that a catalog might work if it was small (20-50 services) but not for hundreds or thousands of services. I think it’s a culture issue not a scale issue, so I don’t think it would work even for a small number of services. But in the end, it’s a moot point since he expects a large number of services. Different reasons, same conclusion. ’nuff said.

However, while I rail against wasting time building a service catalog that won’t do what everyone thinks it will do, I haven’t had a better idea.

Nick does. The Periodic Table of Services. Go read. More of my thoughts on this later.

• I am a few days behind on this, but Joe McKendrick writes an interesting piece on if businesspeople are begging for SOA. It is fascinating because I believe that SOA should come from the business, not because of the delivery mechanism, but because of the results. If services will truly make a business more adaptable and responsive to change shouldn’t all business people desire those results? At the same time they don’t care how that end is achieved, just that it is. That’s where we in the IT industry need to do a better job of working out the details amongst ourselves and show the business how SOA can benefit them. Once we do that we should see more SOA adoptions go smoother and real ROI can be seen.
• Joel Dehlin has blogged on the myth of youth being the ones that use instant messaging, publish and read blogs, participate in social networks, etc. I agree that the technology has been integrated into every layer of society. If you have ever been at the airport or at a Starbucks you know what I mean. Who is it exactly that has a Crackberry addiction? It seems technology has really become a part of our culture, and that it’s not just one age group that is adopting the changes.
• Visual Studio 2008 shell was announced at TechEd yesterday. Even Harry who was on-site missed the release, but it certainly looks cool.
• If you have ever met me you would quickly discover I have quite a background in Unix. That being the case I couldn’t ignore the news that Sun is releasing new blades for the desktop. I had a blade on my desk for several years and it was really a nice system to use. For those that would bash me since I work at Microsoft now I will just say that when you support Solaris boxes, having one on your desk is quite helpful. I don’t take sides in the Holy War. 😄 (via Scoble)

Nick jumps on the durable messaging bandwagon, pointing out that it’s HUGE. Not just huge, or Huge but HUGE. But for my taste, he could emphasis it even more – HUGE – and still not capture just how important I think durable messaging is. But while he could use more bolding and italics, he certainly explains the problem well:

The reason that [reliability] becomes a problem in SOA is because the basic strength of SOA is the message, and the weakest link is the mechanism used to move the message. If we create a message but we cannot be certain that it gets delivered, then we have created a point of failure that is difficult to surpass.

Durable messaging solves two fundamental reliability issues:

1. Transactional Message Send. I want to send a message to some external service as part of a transaction. That is, I only want to send the message if the transaction commits. If the transaction aborts, I don’t want to send the message. The only way to do this is to durably record the intent to send the message within the transaction and then deliver the message after the transaction successfully commits.
2. External System Unavailable. I’m sending a message to an external service that is unavailable at the moment. Maybe it’s a temporary network condition, maybe it’s scheduled downtime, maybe the data center burned down, I don’t know. But because the message is durably stored, I can retry long after the sending transaction has committed. Furthermore, I can continue to retry (until success of course) even if my sending system reboots, fails over to a hot standby or has to be restored from backup (assuming you backed up after message was sent).

However, Nick points out that reliability has to be considered as part of our design, so do Agility, Flexibility, Scalability, Maintainability, etc. etc. etc. Agility and flexibility require standard transport protocols while scalability and maintainability require intermediation. Unfortunately, at this time there is no standard transport that provides intermediation and durability. Nick says that Microsoft’s “platform is lacking here”, but I’d say it’s an industry wide problem.

Nick mentions least three Microsoft technologies that provide some sort of durable messaging – MSMQ, SSB and BizTalk – but they’re all proprietary. The market leader in this space is MQ Series, which is also proprietary. WS-RM was supposed to be support durable messaging, but doesn’t. There is the Advanced Message Queuing Protocol group, which is defining an open protocol for MQ style systems, but without involvement from any major platform vendors I’m hard pressed to see this go anywhere. Personally, I’d love to see the SSB protocol published, and apparently the SSB wire protocol was designed “to be completely SQL Server agnostic.” Here’s hoping that happens.

Nick goes on to call WCF “immature” because of the lack support for message durability. I think that’s somewhat unfair: I think it’s WS-* that’s immature here, not WCF. It’s easy to confuse the two since they’re so joined at the hip in WCF v1. But WCF’s support for MSMQ shows that it can handle durable messaging, even though there is no usable standard for durable messaging in the WS-* stable. Over time, I think WCF will evolve to support a larger variety of messaging scenarios – WS-*, REST, durable messaging, etc. – out of the box. But for those of us who care deeply about durable messaging, WCF’s current lack of support is pretty frustrating.

• Microsoft announces Surface Computing. When can you buy one for your house? Probably not anytime soon. TechMeme has lots more.
• The one piece of swag I want more than anything else at TechEd is an Evil Mastermind shirt.
• Nick Allen notes that WSDL 2.0 has reached “proposed recommendation” stage. I guess having a “recommended” version of WSDL is an improvement over the “note” version. But other than having a RESTful HTTP binding in addition to the SOAP binding – and being longer – what’s new?
• Speaking of description languages, Don Box writes about the Web Application Description Language which looks very REST-y in that it supports specifying both the URI as well as the payload format. Like Don, I agree with Erik Johnson who commented that “people attracted to REST (in whatever form) are rebelling against interface-based programming more than WS-* itself”. I have a longer post on this coming, but suffice to say I’m really souring on interface-based programming.
• Nick Malik writes that WCF is immature because of it’s “lack of a routable, intermediable, declared message durability option”. Yeah, that’s a huge problem in my book too. It also relates to the last bullet – since durable messaging is inherently async, it doesn’t fit well into the interface-based programming model.