Tidings From SD Web Services World

That's the paradox of standards-based technology: everyone can do it, everyone does, product differentiation approaches zero, and vendors (those that survive) need something new to hype. It happened with Web browsers, Web servers and application servers, and it will happen with the emerging crop of Web Services servers. That isn't cynicism. It's pattern recognition.

It's also the mindset that conference promoters have to deal with when putting together a show like SD Web Services World, which took place at Boston's Hynes Convention Center the week of August 27. Compared to blockbusters like Internet World or JavaOne, the SD shows are intimate gatherings of mostly developers. As such, they tend to focus on education, offering high-quality classes and deemphasizing the vendor expo that dominates many bigger events. That was the case in Boston this week, and it turned out to be just what the doctor ordered.

The show's seven tracks covered the topics that developers, managers and IT strategists need to see at this point in the Web Services life cycle:

• .NET Programming
• Java Programming
• C++
• Design and Process
• XML Development
• Web Services: Components and Services
• Web Services: Business-Implementation
• Web Services: Standards and Vocabulary

The first thing to notice about this breakdown is that it shows a refreshing agnosticism towards programming languages. While individual developers tend to hone their skills in a single favorite language, the development community as a whole is, and will remain, multi-lingual. The audience at this conference understood that language neutrality is a key feature of Web Services. What's all the fuss about, anyway, if not the ability to bridge services written in Java, C#, VB.NET and C++ using meta-linguistic (that is, XML-based) standards like SOAP and WDSL?

A related plus was dedicating a track to XML Development. In addition to knowing how to access XML documents from their favorite programming language, Web Services' developers must become familiar with such rapidly evolving standards as SAX, the DOM, XSLT, Namespaces and Schemas. The show offered in-depth courses on these and other XML-specific topics.

I was personally delighted by the show's strong emphasis on methodology. Developers and architects are becoming keenly aware that infrastructure implies engineering, and that a Web Services world demands better, not less, analysis and design. Towards this end, several process gurus were on hand to lecture on their pet approaches: Scott Ambler talked about Agile Modeling, Martin Fowler about Refactoring in Java, Gary Evans about the role of Use Cases in web design, and Robert Martin about Object-Oriented Modeling and Implementation. To my mind, there is no better antidote for hype than listening to these thought leaders derive best practices from first principles.

The Vision Thing

Speaking of thought leaders, Tim Berners-Lee delivered a 50-minute visionary keynote towards the end of the week. An energetic, informal speaker ("I never use slides for a keynote"), Berners-Lee suffers somewhat from "second-novel" syndrome: okay, so you invented the Web, and then ...? I took away two main points from his talk. Addressing the standards community, he urged simplicity as a guiding principle for Web Services, reminding us that the Web itself succeeds because URIs create a content-neutral information space and because HTTP's GET method has no side effects. This distillation of the e-Universe into its essence is truly visionary and deserves to be engraved in stone.

Berners-Lee's second point concerned the Semantic Web, "the idea of having data on the web defined and linked in a way that it can be used by machines not just for display purposes, but for automation, integration and reuse of data across various applications" (W3C, Semantic Web Activity). This certainly sounds consonant with the Web Services agenda, and in fact Berners-Lee asserted their interdependence. I hope not. Because it's an interesting feature of semantic theories - theories about meaning - that they violate Tim's first principle: they're never simple.

The reason semantics is complicated is that meaning is determined by intentionality, and only people have intentions. Computers just do stuff. They're not trying to survive, or to make a million dollars, or to get a girlfriend. A human programmer can model some of these behaviors and try to get a computer to enact the model, but that's a far cry from imparting intention to the machine. Semantic automation also suggests that humans know enough about what they mean to codify it. We don't. We just have enough of a shared understanding of the world to agree on basic exchanges. Can't we codify those exchanges and get computers to enact them? Possibly. The business process/workflow automation agenda has been at it for fifteen years and made some headway. But that's a lot simpler, a lot less ambtitious than imparting meaning to transactions.

"Computers will find the meaning of semantic data by following hyperlinks to definitions of key terms and rules for reasoning about them logically," Berners-Lee wrote in a recent article in Scientific American. Forty years of research in artificial intelligence and two hundred years of epistemology - the philosphy of knowledge - indicate that this will not, in fact, happen. So, net net: keep Web Services simple, and ponder the meaning of things on your next vacation.

Gordon Benett is a technology strategist with over 16 years experience analyzing, architecting and developing information systems. He is currently with Aberdeen Group (Boston, MA), where as a Senior Research Analyst he follows the Enterprise Java and Middleware markets. Gordon founded Intranet Journal in 1996 and remains a reader and contributing author. He welcomes your comments at gbenett@mediaone.net.

Printer Friendly Version