| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
|
||||
|
||||
Nobody expects the spontaneous integration The title of this week's column is stolen from an item[1] I've just posted to my Weblog, with apologies to Monty Python[2]. It's been an interesting week. On Tuesday of last week, I began an experiment[3] to coordinate two sets of Web services: online bookstores, such as Amazon and Barnes & Noble, and online libraries, in particular my own local libraries. The LibraryLookup project[4], as I'm now calling it, took on a life of its own.
Meanwhile, I was supposed to be writing an article for InfoWorld's special section on disruptive technologies. As my project unfolded, it became clear I was in the middle of a disruptive event. By Thursday, the vendor of the library software had withdrawn the Web page on which I'd found the 900 URLs. What had seemed to be an informational Web page had turned out, to the vendor's surprise, to be a directory of Web services. Oops. Another, more pleasant surprise came later that day. Online library services didn't need to be explicitly listed in a directory in order for me to be able to find them. By Googling for the URL signatures of two other vendors' software, I added support for two additional library systems, and for another 400 libraries that use those systems. The library bookmarklet meme propagated over the weekend, mutating along the way, and by Monday there were all sorts of variations being tried. It's delightful to find that such a simple idea can yield such a powerful result. But why are we always so surprised by these things? We should all expect spontaneous integrations, and take it for granted. Yet (apologies again to Monty Python) nobody expects the spontaneous integration. I posed three questions on my Weblog, which I'll briefly answer here. 1. Why was this unexpected? Because we think coordination of distributed resources has to be hard. The Web keeps showing us how it can be easy, but we never quite believe that. We invent fancy remote-procedure-call technologies and forget to make them document-oriented and URI-addressable -- an oversight that is now, happily, being corrected[5]. 2. In what environment would it be taken for granted? In this case, the conditions for easy integration came about purely by accident. Many (but not all) book sites expose URLs that use ISBN numbers. Many (but not all) online library systems can query by ISBN. In a truly service-oriented world, that kind of thing won't be an accident. We will all understand, viscerally, that every Web application is also a service. Sometimes we'll spell out formal protocols, but always we'll consciously use simple affordances (like the ISBN in the URL) with an eye toward integration. 3. How do we create that environment? If you're reading this column, you're probably as jazzed about XML Web services as I am. So we would probably agree that every Web application ought to be built on an XML framework. And that when the user interface is HTML-based, the HTML should be a transformation of a repurposable XML core. And that the engine powering that core should make its services SOAP-callable and (where possible) URI-addressable. But when push comes to shove, we will still tend to fall back on tried-and-true methods: a conventional app server, HTML templates. That doesn't mean, though, that we can't anticipate and encourage recombinant growth[6]. For starters, use HTML doctitles wisely. Libraries that futzed this vital bit of metadata missed a chance to be included in an ad-hoc directory. Design your URL patterns as though you are designing an API -- which, in fact, you are. And here's a great transitional tip. If you can't offer up self-describing XML content, at least use CSS tags to assign structural names, as well as style names, to key data elements. Web apps can't help but be proto-services, whether you plan for it or not. Expect, and encourage, unintended use. 1. http://weblog.infoworld.com/udell/2002/12/17.html#a547 2. http://www.drizzle.com/~lostboy/binaries/Spanish.wav 3. http://weblog.infoworld.com/udell/2002/12/10.html#a535 4. http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html 5. http://www.infoworld.com/articles/op/xml/02/11/07/021107opwebserv.xml 6. http://weblog.infoworld.com/udell/2002/12/12.html#a537 Jon Udell is lead analyst at the InfoWorld Test Center. Contact him at jon_udell@infoworld.com and check out his Weblog at http://weblog.infoworld.com/udell. RELATED SUBJECTS SPONSORED WHITE PAPERS
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||
|
||||||||||