Getting Web Services

When I left Microsoft in 2000, the overall strategy of the company had shifted to some notion of computing as “service.” It was obviously developed by executives high up and being forced-fed top down to all the product units.  This new strategy was nicknamed “.NET,” and soon every product would soon have the “.NET” suffix appended to its name in order to sound “cool.” (This ultimately caused customer confusion and was dropped from every product except Visual Studio.)

I recalled a really vague and unbelievable highfalutin vision memo of “Office as a Service,”  written by a drunk program manager, emailed to all employees in the division. The two points I got then was that Office.NET would be more connected to the Web and that future versions would be sold using an annual subscription model for “services” rendered. In the latter case, it seemed like the one-time licensing model was not sustainable over the long-term, because eventually some version of Office will have every feature that a company needs in which case no more further upgrades would needed. I saw it as a revenue ploy and really did not get the paradigm shift.

A year later into my MBA program, I vaguely heard about the “Hailstorm” initiative at the Microsoft PDC 2001 in which Microsoft would maintain all user’s information in its servers. Hailstorm never materialized because of legal barriers and its chief architect, Mark Lucosky, now works at Google after complaining that Microsoft can’t ship software. One ex-Microsoftee told me that Office 2003 invested heavily in Hailstorm and suffered from a dearth of features as a result.

Fast forward to 2002 and 2003, I increasingly hear noise about “Web services” and later “Indigo” and I keep thinking “here we go again.”

In spring 2004, I attended a DevDay session in which Microsoft introduced the concept of “smart clients.” Smart clients merged the advantages of traditional “rich clients” (desktop applications) and “thin clients” (browser applications). Smart clients are connected but offline-capable through caching. Like rich clients, smart clients utilize local resources. Like thin clients, smart clients are easily deployed and automatically updated. In addtion, smart client applications may also include versions for compact devices and/or browsers, all of which communicate and synchronize with each other through Web services. While I don’t think web services are involved, Outlook is a good example of a smart client, which is smart about online and offline network access. It’s also available on PDAs as Pocket Outlook, synchronizable through ActiveSync, and a rich AJAX online version, Outlook Web Access.

In summer 2004, I attended a couple lectures given by both eBay and Amazon employees on some of the new webservice APIs they exposed, which is when I really started to grasp the potential of webservices. I started seeing various possibilities about how I could use services in my application. I took the time to create toy applications, read and attend lectures about web services and Indigo.

A few months ago, I learned about Delicious Library. It seems that DL uses Amazon APIs to extract information such as thumbnail photos about DVDs and books. If the application also allows Amazon books and videos to be ordered from within, that would also provide a second revenue source through commissions in Amazon’s associate program. There’s probably a opportunity for an application to create a rich client front-end to all the popular e-commerce sites.

 I recently encountered the Shareware Starter Kit includes a number of common webservices for shareware developers.

Last month I played around with XML-RPC and the various blogging APIs (Blogger, MetaWeblog and MovableType). I also read up on Professional Web APIs: Google, eBay, PayPal, Amazon.com, MapPoint, FedEx, which covers web APIs from all the companies in titles plus others. While each website uses different methods such as HTTP-GET(REST), HTTP-POST, and SOAP, they all provide libraries and many of them support multiple protocols. The APIs are remarkably simple, mostly because the APIs are flat. The generic license provided by these firms usually requires a registration and also imposes a daily limit on API usage; these seem intended for business-to-business communication. Any commercial application released to consumers probably requires  direct contact with the company for more lenient licenses. While it’s possible to avoid the APIs and perform HTML-scraping to overcome vendor constraints, APIs provide a legitimate and robust approach that survives legal challenges and periodic site changes.

I eventually see myself incorporating web services in my applications, both my own and those of other companies.

The notion of “software as a service” has gradually become a coherent and unifying story throughout Microsoft. I see it in the .NET framework support for web services and ClickOnce, in Indigo’s attempts to unify the various Windows communications approaches into a simple, common services-based API, in Avalon’s borrowing of UI patterns (deployment, inductive UI, markup, navigation) from the Web. I sense it in Office 12’s continued movement towards XML and network-centric computing, and in Microsoft’s recent embrace of RSS. I can only extrapolate this to the rest of Microsoft’s divisions.

Comments

[hhh]

>> dropped from every product except Visual Studio

Passport.NET

[Jonas Antonsson]

The problem with Web Services is the hype that has surrounded them since they were introduced. The hype has distorted their usability (which is considerable). The hype tends to do that to paradigms, new technology and other aspects - it drowns out the voices that truly grasp what is involved. But then the hype settles and then it finally becomes clear what "the hype really is about".

J#