Brewing a HailStormby Rael Dornfest
Microsoft's announcement of its HailStorm Web services infrastructure on Monday brought about a flurry of reports, opinions, concerns, praise, and initial impressions flowing in from all fronts. "The HailStorm announcement is a shocker, no matter how much MS had prepped us for it ... I think that's all the take-away one can get from the posts on the mail lists, the articles and editorials in various pubs," said Dave Winer of Userland. (For an aggregated view of the day's events, be sure to visit Monday's edition of Dave's ScriptingNews Weblog.)
So what is this HailStorm?
From the user's perspective, HailStorm is Microsoft's new architecture for building user-centric web services, gathering all of your information around you, the user. Rather than attempting to juggle all of the disparate bits of information you've provided various web sites, Microsoft's central Passport service integrates these information silos, locks them up, and hands you the key. It's up to you, the user, to decide what information you share with whom, specify what they're allowed to do with it, and so on. All of this is independent of device, network, and platform; whether you're out and about with your palmtop, on a plane with your laptop, in your cubicle at work, or couch-surfing with WebTV, your data's right there with you in a format befitting the venue.
For developers, HailStorm promises to be an open web services architecture based upon the de facto standard dynamic duo of XML and SOAP. Perl programmers should be able to talk to HailStorm using SOAP::Lite. Creating HailStorm-based services for the Gnome desktop should be a snap with Ximian's SOUP (a play on SOAP) support. And since HailStorm is a component of Microsoft's .NET initiative, Visual Studio.NET fans can drag-and-drop services into their applications.
Reading through Microsoft's HailStorm press release, white paper, and announcement, a few themes jump out at me, inviting a response. The majority of the commentary over the past few days has focused on either the user or developer's perspective; I'll attempt to tackle and balance both. Please bear in mind that this isn't meant to be an in-depth or broad-scoped analysis, but an initial gander with more to come.
"Currently, users have a variety of different applications, devices, services they use daily but those technologies don't work seamlessly with one another, and they require users to adapt to each technology rather than having the technology adapt to them or work together on the user's behalf."
The decentralization meme, beyond the obvious independence from centralized servers and services, has also allowed a certain freedom to rise above the capabilities of the desktop/palmtop operating system. My Windows 98 laptop doesn't innately allow me the functionality to chat with my coworkers, search for extraterrestrial life, or share MP3s with my friends, but it also doesn't forbid me to do so. For the end-user, however, the experience is rather staccato, with the taskbar or system tray brimming with application icons and a different application for each task.
HailStorm offers to provide the glue between the loosely coupled services currently provided by disparate efforts in the peer-to-peer and web services spaces. This means potentially seamless integration between my distributed file-sharing and word processor applications a la Office.
But will this glue be too binding, stifling the creative applications arising from the decentralization meme? By better integrating loosely coupled services with Windows, will Microsoft also be limiting (softly, at least) my view of alternatives to their My* line? Will future versions of Microsoft client software provide easy and obvious access to a menu of services or a prix fixe dinner with an obfuscated a la carte option upon request?
For developers, HailStorm promises two things: framework and users.
On the framework front, Microsoft proposes a clean, open avenue via XML and SOAP for interaction between services, devices, platforms, and languages. If you can make a SOAP call, you're in like Flint. Passport is the central key to all of this, which is both good and terrible for developers. On the one hand, it takes care of user authentication and access control for the users' data. On the other, developers are reliant on this centralized service; obvious issues are security, reliability, and the need to buy into Microsoft being at the very core of your service (and livelihood).
And, of course, developers and service providers are promised users -- gobs of them, 160 million, in fact. "It begins with Passport and it begins with creating a very large base of users that are already provisioned with HailStorm services," said Bill Gates at the HailStorm announcement.
"With HailStorm, users will have even greater and more specific control over what people, businesses and technologies have access to their personal information."
I trust my bank an awful lot with my money. Amazon.com knows at least a subset of what I like to read. Birkenstock knows my shoe size. Southwest Airlines knows when I'll next be in the Bay Area. And never the twain shall meet. Not only do I see the value in keeping this information compartmentalized, I see the dangers in the confluence of disparate bits of personal data. I currently control much of my data through personal access control lists; to hand that functionality over to one company is a leap of faith I'm not ready to take. As for trusting Microsoft with it, well, it would only be half-joking to say that the opposite of "trust" is "antitrust."
Not to say, mind you, that Microsoft's goal isn't admirable. End-users are indeed boggled by the plethora of usernames, passwords, hints, and client-restrictions they're forced to juggle as they meander the Internet. Translating this into real-space, the Internet does feel at times like a vast neighborhood of speakeasies. If Microsoft can enable the end-user to purchase a quart of milk, rent a video, and drop in on a friend without having to flash their passport (pun intended) at every step, they'll indeed see some uptake.
Will the end-user go for it? Probably. The trepidation surrounding online credit-card transactions has all but disappeared, and this comfort has been extended to making other personal information available online; I'm amazed at the lack of hesitation to provide (often optional) information to sign up for a newsletter or to download a bit of software. How many people don't think twice about keeping unencrypted for-your-eyes-only information (personal finances, company memos, family schedule) on their laptops just because Windows prompts you for a (ludicrously useless) username and password when starting up?
Pages: 1, 2