Effective description, discovery, and integration

The Rodney Dangerfield of Web services standards is clearly Universal Description, Discovery, and Integration. UDDI don't get no respect. Its original conception -- a global e-marketplace for services -- looks, for now, like a dot-com-era fantasy.

Inside enterprises, however, it does serve as a convenient place to catalog services. And the more extensible information model in Version 3 of the standard has raised hopes that UDDI may yet prove to be the framework on which we'll hang operational and policy controls.

Maybe so, but we'll still need to account for how people actually describe, discover, and integrate services. Back in June, for example, an IBMer named James Snell wrote to point me to a service he'd created to map the locations of recent earthquakes. He composed it -- in a matter of minutes -- from a set of constituent services, including Google Maps, an RSS data feed, and an online XSLT transformer. Snell was impressed by the quick integration. I was equally impressed by the kinds of description and discovery that made it possible.

These services were listed in no formal catalog. Instead they were described on Web sites and blogs and were discovered by way of Google. This wasn't a fluke. When reusable services exist on the public Web, a bit of searching is all that's required to discover which ones are available, check out the reputations of their developers, see examples in use, and learn how to apply them for your own purposes.

Inside the enterprise, of course, you're not just hacking together Google Maps mash-ups. You're mainly trying to translate your business' services into software services that model what your business does, while simultaneously wrapping, reorganizing, and consolidating a boatload of legacy IT cruft. Using a services repository to coordinate this tricky maneuver -- and to manage your services infrastructure as it evolves -- makes great sense. But the repository is not the most natural venue for description and discovery.

People describe things by telling stories to one another, and they discover things by searching for them. Capturing these narratives was always a good idea, and it matters more now that SOA is finally enabling us to deliver on the ancient dream of software reuse. What's available, who remembers the back story, and where the gotchas lurk -- these are the kinds of institutional knowledge that we want to nurture and mine. So it's no surprise that wikis and blogs are growing like kudzu in the enterprise. Make sure you can search those sprawling conversations effectively, and you'll discover all kinds of things that are, or should become, services.

The roving eye of your in-house Google need not confine itself to human chatter. Searching the documents and transactions flowing across your services network can yield powerful insights. Verizon CIO Shaygan Kheradpir calls this "Googling the enterprise." After Verizon exposed interfaces to its services, Kheradpir told me, it became possible to crawl them just as Google crawls the Web.

Now the corporate search engine can deliver every document or transaction related to a customer, across the entire far-flung enterprise, with subsecond response times. It's sloppier than querying the data warehouse, Kheradpir says, but more inclusive. Coupled with the human ability to scan and interpret, it's a great way to integrate something that's really hard to discover: a coherent view of the customer.