SD West: SOA: The Next Big Thing (Keynote)

Dave Chappell delivered an entertaining keynote.  Again, this was targeted squarely at enterprise application developers.  I felt a bit like a tourist in a foreign country -- happy to be there, interested, but a bit puzzled and probably missing some of the shared cultural nuances.  (Despite having created some enterprise development tools, I've never actually worked as an enterprise developer.)

Dave cut the Gordian knot involved in defining service oriented architecture ("the debate is both endless and pointless") by stating that it's defined by the dominant technologies:  A service is what the dominant products say it is -- and WebSphere and .NET are the dominant products, so services means SOAP and WS-*.  And I'm not sure, but I think he defines 'dominant products' as 'whichever platforms have the most market share among vendors selling tools to enterprise developers'.  Which of course rules out anything that doesn't help sell platform tools :^).  I glance at the Internet, which is mysteriously working again, and verify that Dave Chappell is an old-school DCOM guy.  He seems very happy that the vendors are finally agreeing on a shared standard for communication; after the CORBA/DCOM/RMI wars, I imagine so.

He did have some useful points to make about moving to SOA within an organization, identifying two major approaches:  Top down, in which you identify business needs, document requirements, design an architecture, and implement the services in a well planned, sensible way.  The pros are that this is elegant, clean, and sensible; the cons are that it's (nearly) impossible.  Requires high investment and long-term business buy-in.  He recommended the bottom-up approach (just build one service, then another, then start thinking about central SOA issues such as security and management) as a practical if ugly approach.

He presented a toy example using C# code.  Now, his main points were about the orthogonality of OO design and service architectures, which is all well and good.  But I felt that the choice of an example class with "add(x,y)" and "subtract(x,y)" methods which get turned into web services sort of obscures the question -- why would we want to do that?  It's a ridiculous web service.  Why not pick a toy example that actually makes some tenuous sense as a web service?  For example,a word definition lookup service?

In the short Q&A period, one person asked the obvious question:  What about the REST-ish approaches that so many service providers such as Google, Yahoo!, etc. are using to expose services?  Dave's answer was somewhat revealing, but as a tourist I'm not sure I can properly interpret it.  He said, #1, web services are defined by SOAP and WS-* because that's what the dominant vendors say; and #2, he doesn't "get into SOAP vs. REST debates because the REST community..." and there he paused, and looked thoughtful, and then reiterated "I don't get into SOAP vs. REST debates".  He sure seemed uncomfortable to me.

(Side note:  My spell checker suggests "DOOM" as an appropriate substitute for "DCOM".  Sometimes I think it's really acquired AI and it's just toying with me.)