The undiscovered art of locating and understanding services is a prerequisite for creating successful composite applications. Systinet's launch last month of its Business Services Registry was a helpful step up from the bare A2A discovery capabilities of UDDI, but in its current form it's still of more relevance for those who want to compile service inventories and monitor compliance to corporate standards than it is to developers. Thanks to an introduction from Systinet, I had a fascinating conversation earlier today with Steven Rdzak, infrastructure architect at Level 3 Communications, a longstanding user of Systinet Registry, its basic UDDI product, and I learnt a lot about what sort of things developers need to see in a registry/repository if it's to be a really useful tool for service assembly.
One of the most telling needs that Steve revealed was for documentation. When developers are assembling services to create a composite application, they need to know much more than what's in the WSDL and a basic UDDI entry. UDDI is fine for automated discovery of predefined services at run time, but developers need much more information at design time: information about undocumented parameters, quality of service commitments, billing implications and many other considerations.
This brought to mind my experience of Grand Central's Business Services Network, which I recorded in a posting earlier this week. Grand Central has gone the first step of providing a directory of prequalified services, but the information about those services is pretty rudimentary, and is much less than I (or anyone else) really needs to efficiently build composite applications out of multiple services. As my posting made clear, the process designer gives you enough to deal with as it is without having to delve into WSDLs to tease out what all the services are capable of. Effective reuse depends on much more extensive and better organized documentation.
My conclusion, then, is that service discovery is an evolving and many-faceted art. By happy coincidence, I came across a number of items this week that reinforce and illuminate that thought.
# Service classification. We need some kind of effortless classification of services that makes it easier to locate useful functions. An interesting article about Flickr, the online photo library service, notes that "Flickr treats digital photos as what they are, digital objects on a network, rather than like pieces of paper in a book." I wonder if Flickr's approach to collaborative organization of network objects is something that perhaps could be applied to other classes of object too, such as podcasts, service components, etc.
# Service archaeology. Grand Central's CTO, Dave Linthicum, has a little-known blog that he pointed me to this week, and one of the several interesting postings notes that "my prediction is that one of the best paid jobs in 2005 will be engineers specializing in Web services enablement of legacy systems. I'll call them service archeologists." Yes, there's certainly going to be a lot of digging out (rather than simply discovery) of services going on and not just from legacy systems.
# Service creativity. Once the services have finally been made meaningfully available, then the games really begin. Zazzle, a rapidly expanding new venture that allows users to design their own T-shirts, mugs, etc, demonstrates the creative power unleashed when a business delivers manufacturing-as-a-service in a network-savvy way: "At Zazzle ... We strive to enable a venue and marketplace for anyone with an idea, design, or creative work that would otherwise never be seen or appreciated." Zazzle heralds the beginning of the end for 'broadcast' manufacturing. Why buy the same as everyone else when everyone can design their own product? (Yes, this applies to enterprise software as much as it applies to T-shirts and mugs).
# Service deployment. Laszlo struck a new blow in its battle to bring its rich Internet application platform to the masses with the launch of Blogbox.com: "Blogboxes provide exciting, instantly deployed functionality for your blog or Web site. They are free for non-commercial use. Enjoy them and spread the good word!" Offering embedded sound, photos, time, weather and other services to blog owners, this is a viral marketing ploy to get Laszlo's technology out into the world that might just work.
# Service education. It sounds like Adam Blum has just taught one helluva course at Cal Berkeley, bringing in speakers like Adam Bosworth and Roger Sippl. "As far as I know its the only course focus on building schema-first coarse-grained document-oriented web services," says Adam. His blog provides links to some of the slide decks. Meanwhile, his former colleague Radovan Janecek points to an excellent rundown of the key components of web services and what they're for: The Web Services Kernel.