Linking to the unexpected

A serendipitous experiment by Jon Udell has demonstrated the disruptive power of web services, as he describes in his InfoWorld column this week. The experiment began with the discovery that the ISBN numbers used to identify books in Amazon's URLs can be linked to the same information in the online catalogues of US public libraries. This gave rise to a completely new application which Jon dubbed LibraryLookup [I've updated this link following Jon's comment].

None of this would have been possible if the ISBN numbers had not been exposed within Amazon's URL (more properly termed the URI, or uniform resource identifier). Last week, a product manager at a CMS vendor asked me whether he should be worrying about adding support for SOAP yet. My response was that, when dealing with content, I would recommend thoroughly investigating a simpler URI-based approach rather than moving directly to SOAP, which may prove more complex than is necessary. As Jon writes in his column, "We invent fancy remote-procedure-call technologies and forget to make them document-oriented and URI-addressable." Making information document-oriented and URI-addressable should come first.

An essay by Craig Johnson reflecting on Jon's experiences highlights the advantage of exposing information in the URI: "any environment that exposes information via URL is likely to see this kind of spontaneous or serendipitous activity because it doesn't require coordination and planning. The only constraint is trust. When information is made available via URL the producer will want to trust the consumer community to not abuse the resource and the consumer will want to trust the producer is not going to disappear." And Jon himself concludes with this advice:

Use HTML doctitles wisely ... 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.

By following this advice, you'll be enabling your content and/or applications to participate in activities that no one has yet dreamt of, but which will become possible by combining different items of information together in unexpected ways. You may feel that's too scary a thought, and certainly it's not as reassuring as knowing exactly who will be using your information and for what purposes. But if you're in the business of making content or services available on the Web, then you can take comfort from the thought that these activities will be deploying your offerings more widely and richly than you could ever have imagined.
posted by Phil Wainewright 2:19 PM (GMT) | comments | link

Pluggable IT

The adoption of web services and subsequent moves to an on-demand, service-oriented architecture spell the end of the traditional IT organization, writes CBDi Forum in the latest edition of its newsletter: "... the real breakthrough will be when businesses acquire services from the most appropriate place, not simply from their own, contracted IT organization. This will be a market that has huge competition that will have a highly beneficial effect for providers and consumers alike."

The article highlights a very significant difference between traditional outsourcing and on-demand service provision. Outsourcing, as CBDi notes, is generally only attempted for processes and functions that are already stable and well-defined. It is not adaptable to changing business needs. In contrast, the very notion of on-demand implies that it should be easy to modify the service configuration or to move from one provider to another. Component-based on-demand services are thus seen as the foundation for enabling the adaptable enterprise.

The article is a teaser for a fuller report, The Service-Oriented Software Chain, discussing how the traditional IT function will eventually be replaced by software-based reusable business services [browse more research]. This concept of pluggable service provision is very attractive, but it's more than a case of simply moving to a service-oriented technology architecture. Open competition implies that customers can easily move from one provider to another, and that can only happen when the business aspects of service provision are automated, which adds significantly to the scale of the task. Elements that need to be catered for include the following:

• Control — Service consumers need to be able to configure the content and quality of the services being provided


• Visibility — Providers must ensure consumers are kept fully informed about the content and quality of services


• Contracts — Conditions of service, pricing and service level agreements all need to be implemented within the service provisioning infrastructure


• Billing and settlement — Every participant in a multi-provider service infrastructure needs to be paid in accordance with their contracted contribution.

None of these elements are currently standardized, as all the focus of development work to date has been on making the technical infrastructure work. The commercial infrastructure doesn't even exist on paper.
posted by Phil Wainewright 4:55 AM (GMT) | comments | link

Another $17.9m for Curl's rich client mission

Curl, the startup founded by MIT scientists to create a rich client-side platform for web applications, announced closing a Series D funding round of $17.9 million yesterday. Led by existing investors Baker Capital and Equity Group Holdings, the round brings its total equity funding over the past four years to more than $60 million. According to the Boston Business Journal, the company also received a $5 million research grant when it spun out of the MIT research project from which it takes its name.

Curl competes with Macromedia, Altio, Esual and Sun's Java language, among others, in the quest to move beyond the limitations of HTML-based pages for the delivery of rich client-side application functionality. I've noted in several recent postings why I believe the rich client is set to come to the fore as a key component of the web services application architecture. Curl's investors evidently take the same view, committing an exceptionally large fourth round to help the company expand its sales and marketing efforts.

Curl is firmly focussed on the enterprise market, where its inability to execute on any platform other than Windows is less of a disadvantage than in other spheres, but which also leaves it vulnerable to potential outflanking moves by Microsoft. Its announced customers include Japan Telecom, Siemens and Datastream, and typical use examples consist of complex visual presentation and manipulation of data at the client, with server exchanges limited to one-time code downloads and on-demand updates of XML data.
posted by Phil Wainewright 2:23 AM (GMT) | comments | link

Hanging loose with transformation

All the fuss about Microsoft using proprietary XML schema in Office 11 may be missing the point. It's true that the use of a proprietary schema means that Office 11 documents won't be directly compatible with third-party products, even though the content will be stored using XML. But Microsoft says it will be possible to access the content using another W3C standard called XML Schema Definition language (XSD), according to a report on CNet today, How open is the new Office?.

Critics say that's not good enough, and that everyone should use the same, shared schema so that documents created in Office could be opened and edited in any other suite, such as Corel WordPerfect or Sun StarOffice. Microsoft counters that it's up to competitors to support XSD, which would make the files usable from within competing products. "That's absolutely true. You can put my name to it," Jean Paoli, Microsoft's XML architect, told CNet.

Much to my surprise, I'm inclined to side with Microsoft here. Forcing everyone to use a single, immutable file format is far too reminiscent of the bad old days of tightly coupled systems, it seems to me. Having an agreed standard that allows transformation from one file format to another is much more in keeping with the loosely coupled principles of a service-oriented architecture. Standardizing on XSD ought to mean that no single file format dominates, and should encourage innovation rather than throttling it for the sake of conformance to a prescriptive standard.

Of course, it also means that you'll have to go back to the originating program if you want to edit the formatting as opposed to the content. But users will be able to choose where they format the content, which is likely to benefit providers and vendors of tools that cater for formatting needs neglected by Microsoft. None of this lets Microsoft off the hook over how much it plans to charge to license its schema to other vendors (presumably XSD transformation tools would have no choice but to pay a license fee if Microsoft decided to levy one). But it does illustrate that there is more than one way to be open in a loosely coupled world.
posted by Phil Wainewright 10:09 AM (GMT) | comments | link