• Sorry for the posting lag. Had a few technical difficulties around here. In the process of moving hosts, so expect more glitches.
• My talk at the p&p Summit on Monday went really well. At least, it felt good and the applause at the end felt genuine. I recorded the audio on my laptop, so I’ll be posting a Silverlight version as soon as I figure out how to adjust the levels so their somewhat consistent. Paraesthesia and #2872 have reactions.
• Speaking of the p&p Summit, Scott Hanselman posted his ASP.NET MVC demo from his talk. Said ASP.NET MVC bits aren’t available yet, so you can’t, you know, run the demo for yourself. But at least you can review what the ASP.NET MVC code will look like.
• I stopped by the SOA/BPM conference last week and saw Jon, Sam and Jesus among others. Spent quite a bit of time talking to Sam and his Neudesic colleagues about this “physically distributed/logically centralized” approach that I think is hogwash. It sounds to me like Neudesic approach is really federated not centralized, though I’m not sure David Pallmann would agree. Federated makes much more sense to me than centralized.
• Nick Malik continues his series on SOA Business Operations Model. I especially like his point that this isn’t a series of choices, you need to “look at your company and try to understand which model the business has selected.”
• The first CTP of PowerShell 2.0 is out! Check out what’s new on the PowerShell team blog and Jeffrey Snover’s TechEd Presentation. (via Sam Gentile)
• Soma announced updates to VC++ coming next year, including TR1 support and a “major” MFC upgrade to support creating native apps that look like Office, IE or VS. I get supporting TR1, but the idea that people are clamoring for MFC updates is kinda surprising. Many years ago when I first came to MSFT, a friend asked “But don’t you hate Microsoft?” to which I responded “No, I just hate MFC”. Obviously, not everyone agrees with that sentiment.
• Steve Vinoski thinks there’s no hope for IT. Funny, I keep agreeing with Steve’s overall point but disagreeing with his reasoning. I still don’t buy the serendipity argument. I like compiled languages. And I think he’s overstating the amount of “real, useful guidance” for REST floating around. Basically, there’s “the book“.
• In widely reported news, Windows Live launched their next generation services. Don’t bother with the press release, just go to the new WL home page.
• Speaking of WL, Dare Obasanjo points to the Live Data Interactive SDK page where you can experiment with the WL Contacts REST API. It gives you a good sense of how the Web3S protocol works. Pretty well, IMO. However, how come WL Contacts Schema doesn’t include some type of update timestamp for sync purposes? If you wanted to build say a Outlook to WL Contacts sync engine, you’d have to download the entire address book and grovel thru it for changes every sync.
• Speaking of Web3S, I’d love to see some info on how one might implement a service using Web3S. Yaron Goland positions Web3S as an alternative to APP that WL developed because they “couldn’t make APP work in any sane way for our scenarios”. I’m sure other folks have similar scenarios.

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

Steve Vinoski has raised a bit of a flame war by admitting he has lost the ESB religion. Given that I’ve never been a fan of ESB’s anyway, there’s a lot there that I agree with. In particular I liked the description of “magical framework” middleware, blaming enterprise architects for driving ESB’s as the “single integration architecture” even though a single *anything* in the enterprise is untenable and his point that flexibility means you don’t do any one thing particularly well.

However, Steve goes on to bash compiled languages and WS-* while suggesting the One True Integration Strategy™ is REST + <insert your favorite dynamic language here>, then acts surprised that the conversation denigrates into “us vs. them”. When you start by saying that compiled language proponents “natter on pointlessly”, I think you lose your right to later lament the depreciating level of conversation .

All programming languages provide their own unique model of the execution environment.  Dynamic languages have a very different model than compiled languages. Arguing that this or that model is better for everyone, everywhere, in all circumstances seems unbelievably naive and arrogant at the same time.

On the other hand, I do agree with Steve’s point that most developers only know a single programming language, to their detriment. One language developers often miss a better solution because their language of choice doesn’t provide the right semantics to solve the problem at hand. Developers could do a lot worse than learn a new language. And I don’t mean a C# developer should learn VB.

The most pressing example of picking the right language for the right problem today is multi-threading. Most languages – including dynamic languages – have shitty concurrency semantics. If you’re building an app to take advantage of many-core processing, “mainstream” apps like C#, Java and Ruby won’t help you much. But we’re starting to see languages with native concurrency semantics like Erlang. Erlang is dynamically typed, but that’s not what makes it interesting. It’s interesting because of it’s native primitives for spawning tasks. I don’t see why you couldn’t add similar primitives for task spawning to a compiled functional language like F#.

As for REST vs. SOAP/WS-*, I thought it was interesting that Steve provided no rationale whatsoever for why you should avoid them. The more I listen to this pissing match debate, the more I think the various proponents are arguing over unimportant syntactical details when the semantics are basically the same. SOAP is just a way to add metadata to an XML message, much as HTTP headers are. WS-* provides a set of optional message-level capabilities for handling cross-cutting concerns like security. Past that, are the models really that different? Nope.

For system integration scenarios like Steve is talking about, I’m not sure how important any of the WS-* capabilities are. Security? I can get that at the transport layer (aka HTTPS). Reliable Messaging? If I do request/response (which REST excels at), I don’t need RM. Transactions? Are you kidding me? Frankly, the only capability you really need in this scenario is idempotence, and neither REST or SOAP provides any standard mechanism to achieve that. (more on that in a later post)

I understand that some vendors are taking the WS-* specs and building out huge centralized infrastructure products and calling them ESBs. I think Steve is primarily raging against that, and on that point I agree 100%. But Steve sounds like he’s traded one religion for another – “Born Again REST”. For me, picking the right tool for the job implies much less fanaticism than Steve displays in his recent posts.

John Heintz responded to my serendipitous reuse post. Nice to see I misunderstood his opinions about how easy RESTful systems are to integrate:

I didn’t mean to imply that building RESTful system would lead to magical integration without any hard work. I can see how that came across in my post, and I guess I got the reaction I asked for 😉

I get the feeling that John would be a good guy to have a beer with.

John spends most of his post writing about the SOA in the Real World book. I’ve flipped thru it and I’m familiar with the model (it is my old team after all) but I haven’t read it so I don’t really want to comment about the book specifically. But there were two things John mentioned that I did want to comment on.

First, at the end of his post John writes:

Can some of the constraints of REST be applied to SOA? Absolutely. I think an asynchronous, message-passing architecture with a uniform interface would be astoundingly interesting! I’m not the only one: see MEST, AMPQ, and Erlang.

This goes back to a REST question I asked two months ago: is it still REST if you don’t use HTTP? I’m guessing John would say yes.

I might be going out on a limb here, I’ll bet the core of John’s problem with SOA is how toolkits like WCF all but force you to build RPC style services that can easily be modeled as method calls. That’s certainly one of my problems with SOA. Tim Ewald said it best:

It’s depressing to think that SOAP started just about 10 years ago and that now that everything is said and done, we built RPC again. I know SOAP is really an XML messaging protocol, you can do oneway async stuff, etc, etc, but let’s face it. The tools make the technology and the tools (and the examples and the advice you get) point at RPC. And we know what the problems with RPC are. If you want to build something that is genuinely loosely-coupled, RPC is a pretty hard path to take.

If SOA == RPC and REST == loosely coupled messages, then I’ll start growing dreadlocks right now. Frankly, as Tim says, I think it’s a problem with the tools (I’m looking at you WCF) and not the underlying architecture, but how many people can distinguish the architecture from the tools? Not many, I’m afraid.

Second, John asks an interesting question:

Where are the SOA mashups?

That’s easy! They’re inside the firewall where you can’t see them! 😉

Seriously, I’m not sure about “SOA” mashups, but I’m working with what you might call a huge “enterprise” mashup system inside Microsoft. Our Enterprise Data Integration Services push around massive amounts of data to downstream systems. There are over fifty datasets in production, each with scores of tables, millions of rows and hundreds of subscribing systems. One example, our Products dataset, has over 100 tables and nearly 300 subscribing systems.

Is it “service oriented”? No, but then again it was originally developed ten years ago on SQL 6.5. But is it a mashup? Is it an “application that combines content from more than one source into an integrated experience“? Yep. Is it easy to work with? No, but guess why I’m involved? We’re looking at ways to “modernize” the system. Am I going to build RPC style services as part of this modernization? Hell, no.

So John, am I right or wrong about that beer?

Thanks to Technorati, I found this post by John Heintz. He’s checking out John Evdemon’se-book on SOA and has a problem with this overview:

SOA is an architectural approach to creating systems built from autonomous services. With SOA, integration becomes forethought rather than afterthought. This book introduces a set of architectural capabilities, and explores them in subsequent chapters.

To which John H. responds:

I, for one, would rather build on an architecture that promotes integration as an afterthought, so I don’t have to think about it before hand!!!

Yeah, I’d rather not have to think about integration before hand either. On the other hand, I want integration that actually works. It sounds like John H. is suggesting here that REST somehow eliminates the need to consider integration up front. It doesn’t. Consider this: if you’re building a Web 2.0 site then you are expected to expose everything in your site via APP, RSS and/or RESTful POX services. In other words, the Web 2.0 community expects you to have the forethought to enable integration. If you don’t, Marc Canter will call you out in front of Bill Gates and Tim O’Reilly.

This integration by afterthought approach seems to be big among RESTifarians. John H. links to a REST discussion post by Nick Gall advocating the principle of generality, “unexpected reuse” and “design for serendipity”. Money quote:

The Internet and the Web are paradigms of Serendipity-Oriented Architectures. Why? Largely because of their simple generality. It is my belief that generality is one of the major enablers of serendipity. So here I immodestly offer Gall’s General Principle of Serendipity: “Just as generality of knowledge is the key to serendipitous discovery, generality of purpose is the key to serendipitous (re)use.”

Serendipity means “the accidental discovery of something pleasant, valuable, or useful“. “Serendipitous reuse” sounds an awful lot like accidental reuse. Most enterprises have been there, done that and have nothing to show for their efforts or $$$ except the team t-shirt. Yet Tim Berners-Lee believes “Unexpected reuse is the value of the web” and Roy Fielding tells us to “Engineer for serendipity”. What gives?

First off, enterprises aren’t interested in unexpected or serendipitous reuse. They want their reuse to be systematic and predictable. The likelihood of serendipitous reuse is directly related to the number of potential reusers. But the number of potential reusers inside the enterprise is dramatically smaller than out on the public Internet. That brings the chance for serendipitous reuse inside the enterprise to nearly zero.

Second, enterprise systems aren’t exactly known for their “simple generality”. If Nick’s right that “generality of purpose is the key to serendipitous (re)use”, then enterprises might as well give up on serendipitous reuse right now. As I said last year, it’s a question of context. Context is specifics, the opposite of generality. Different business units have different business practices, different geographies have different laws, different markets have different competitors, etc. If an enterprise operates in multiple contexts – and most do - enterprise solutions have to take them into account. Those different contexts prevent you from building usable – much less reusable – general solutions.

Finally, I think the amount of serendipitous reuse in REST is overstated. If you build an app on the Facebook Platform, can you use it on MySpace? Nope. If you build an app that uses the Flickr services, will it work with Picasa Web Albums? Nope. Of course, there are exceptions – pretty much everyone supports the MetaWeblog API – but those exceptions seem few and far between to me. Furthermore, the bits that are getting reused – such as identifier, format and protocol – are infrastructure capabilities more suitable to reuse anyway. Serendipitously reusing infrastructure capabilities is much easier than serendipitously reusing business capabilities, REST or not.

The problems that stand in the way of reuse aren’t technology ones. Furthermore, the reuse problems face by enterprises are very different than ones faced by Web 2.0 companies. REST is a great approach, but it isn’t a one-size-fits-all technology solution that magically relegates integration and reuse to “afterthought” status. Serendipity is nice, when it happens. However, by definition it’s not something you can depend on.