Dave Chappell delivered an entertaining keynote. Again, this was targeted squarely at enterprise applicationdevelopers. I felt a bit like a tourist in a foreign country -- happyto be there, interested, but a bit puzzled and probably missing some ofthe 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 orientedarchitecture ("the debate is both endless and pointless") by statingthat it's defined by the dominant technologies: A service is what thedominant products say it is -- and WebSphere and .NET are the dominantproducts, so services means SOAP and WS-*. And I'm not sure, but Ithink he defines 'dominant products' as 'whichever platforms have themost market share among vendors selling tools to enterprisedevelopers'. Which of course rules out anything that doesn't help sellplatform tools :^). I glance at the Internet, which is mysteriouslyworking again, and verify that Dave Chappell is an old-school DCOMguy. He seems very happy that the vendors are finally agreeing on ashared standard for communication; after the CORBA/DCOM/RMI wars, Iimagine so.
He did have some useful points to make about moving to SOA within anorganization, identifying two major approaches: Top down, in which youidentify business needs, document requirements, design an architecture,and implement the services in a well planned, sensible way. The prosare that this is elegant, clean, and sensible; the cons are that it's(nearly) impossible. Requires high investment and long-term businessbuy-in. He recommended the bottom-up approach (just build one service,then another, then start thinking about central SOA issues such assecurity and management) as a practical if ugly approach.
He presented a toy example using C# code. Now, his main points wereabout the orthogonality of OO design and service architectures, whichis all well and good. But I felt that the choice of an example classwith "add(x,y)" and "subtract(x,y)" methods which get turned into webservices sort of obscures the question -- why would we want to dothat? It's a ridiculous web service. Why not pick a toy example thatactually 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 suchas Google, Yahoo!, etc. are using to expose services? Dave's answerwas somewhat revealing, but as a tourist I'm not sure I can properlyinterpret 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 "getinto SOAP vs. REST debates because the REST community..." and there hepaused, and looked thoughtful, and then reiterated "I don't get intoSOAP vs. REST debates". He sure seemed uncomfortable to me.
(Side note: My spell checker suggests "DOOM" as an appropriatesubstitute for "DCOM". Sometimes I think it's really acquired AI and it's just toying with me.)