Last week, online retailer Amazon.com threw its weight behind Web services with the launch of a new developer toolkit and application programming interface (API), which makes its content accessible via XML Web services (see Amazon.com Enters the Web Services Age).
| Read and React |
| "Without the means to bill for service consumption and make a fair distribution of the proceeds to participants, the next generation of Web service providers could rapidly become as bankrupt as the last." Give us your feedback in the ASPnews Discussion Forum |
To make sure there was a small portfolio of applications ready to celebrate the launch, Amazon encouraged its own techies to build sample applications, which it has linked to from the 'how-to' section of its API pages. One of the most acclaimed so far is Amazon Lite, which offers a lightweight search engine utility for finding books and products on Amazon. Another is Book Watch Plus, which combines information from several different sources — first it looks up the top ten books cited by recently published Weblogs, as measured by OnFocus.com; then it uses Google's API to add recent citings of the books at online news sites; finally it uses Amazon's API to add a 'customers also bought' list for each title.
When Google launched its Web services API in April, similar pump-priming meant that it was a matter of days — if not hours — before applications started to appear (see Google Continues Flirt with Web Developers). The wildfire adoption was fanned by the network of self-published and community Weblogs that many developers participate in — as I described at the time (see Glimpses of a Shared Web) — and there's been equivalent enthusiasm for the Amazon Web services toolkit.
Where Are We Now?
But you may well wonder where any of this gets us. Last year, I noted the parallels between the current hype about Web services and the same excitement that once surrounded Java and Web browsers back in the mid-1990s (see It's Just Like 1995 Again). Just as it was with Java in 1995, so it is with Web services now: "It still boils down to adding new bells and whistles to our Web sites."
But just pause there and take a look at what it is we're adding. This is not history going round in aimless circles. There's an upward spiral of development going on, with each new revolution building on the foundations of the last. Back in 1995, we were astonished at our ability to connect individual visitors to dynamic content held on a single Web site. Today, Web services standards like XML, HTTP, SOAP and WSDL allow us to easily aggregate services from multiple sources that pool the collective decision-making of thousands of individual Web sites and their users.
It means that Google can not only offer a search engine, it can offer a search results service that is adaptable to the specific requirements of the subscribing application. It means that Amazon.com can not only sell books over the Web, it can offer a book-selling capability that can be embedded into an affiliate's Web site, or simply provide information about book buying patterns or topic linkages for integration with external decision analysis tools.
The Evolution Continues
What we're really talking about here is the ability to offer service components over the Web — a next-generation form of application service provision that has a far more certain chance of survival than yesterday's ASP model of attempting to rent out access to hosted application packages.
Yet there's still a vital ingredient missing before this new wave of service component providers can become a sustainable model. How are they going to make money?
Looking back, I don't suppose the Internet would ever have really got going if it hadn't been for the folly of the dot-com boom. In the early days there was strong resistance from Internet enthusiasts against the commercialization of the Web. Venture capitalists, and later ordinary investors, swept away potential objections by underwriting the cost of providing online content and services for free. They effectively mortgaged their capital against future revenues that they believed would more than repay their initial investment.
Money Changes Everything
Of course, those days never arrived, and in the meantime, virtually no meaningful work has been done to develop the technology to accurately measure usage, raise bills, collect payments and distribute settlements for multi-tiered component service delivery. I know certain vendors will e-mail me to dispute that assertion, but the fact remains that Google and Amazon have both introduced their APIs as limited-use free trials precisely because no-one has a clue how they will charge for them once they decide they need to.
In today's financially sober climate, this will rapidly become a stumbling block to the development of new services, and even to the progression of proven trials into production service offerings. It's a telling irony that, despite all the funds that have been sunk into building the infrastructure of the Internet, so little has been expended on creating a technology infrastructure for collecting its revenues. Without the means to bill for service consumption and make a fair distribution of the proceeds to participants, the next generation of Web service providers could rapidly become as bankrupt as the last.
Do you have a comment or question about this article or the ASP industry in general? Speak out in the ASP Discussion Forum.
IE 7
Firefox 2.0