Export (0) Print
Expand All
Expand Minimize
1 out of 5 rated this helpful - Rate this topic

A Quick Introduction to HailStorm

As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see Internet Explorer Developer Center.

Robert Hess
Microsoft Corporation

May 14, 2001

Lately, in addition to talking with various people about .NET and Web Services, I've also been dealing with a new set of services that Microsoft recently announced. It is so new, in fact, that it is only known by its codename of "HailStorm."

While perhaps not the first question that I encounter, one of the more frequent questions is, "What does the codename mean?" Like any good codename, the term HailStorm has no relationship to the product at all. But unlike most codenames at Microsoft, it also has no real relationship to anything. Codenames normally fall into groupings such as well-known cities, names of ski resorts, species of trees, famous poets, celestial bodies, or other such groupings in which subsequent releases can use another name in the series. However, HailStorm breaks that mold.

Here is how it came to pass. Like most companies with internal networks, when people put their systems online, they try to give them interesting or at least memorable names. The challenge of course is finding a name that somebody else isn't already using, but still end up with something a little more imaginative than RBH_15. Long before the HailStorm project was started, one of the people now in charge of HailStorm was trying to find a good name for one of his servers, and after trying several different names, he finally settled on HailStorm.

Okay, so that might be an interesting story, but totally useless. You probably are more interested in understanding a little more about what HailStorm is, and what you might be able to do with it.

A shortened explanation would be that if you think of .NET as providing the technical infrastructure for the development of Web-based distributed applications, then HailStorm is built on top of .NET and provides some of the fundamental resources that a Web-based distributed application might need in order to actually share information between applications.

Another way of thinking of this would be to think of .NET as the definition of the "file system," or how an application would interact with the storage system of a computer for opening, closing, reading, writing, and interrogating the underlying data store. The file system itself has no control or interest in the meaning, or even in the format of the data stored in a file, and while through the use of the file system one application can easily open up the file that another application wrote, there is nothing that ensures that the data will be understandable or even readable by the second application.

This is where HailStorm steps in. You can think of it as being the definition of ASCII text, which means that even something as simple as text information can be shared between two applications, or CSV which provides a common format for exchanging tables of information, or RTF which is a way that word processing applications can save their data so that other applications can read them. Through these, and other common data interchange methods, it is possible for users to store their information in a commonly understood format, and for multiple applications to share and expose this information in order to interact with other applications, as well as aggregate the information into unique and useful views.

Like any sort of general comparison, the above fails to fully describe HailStorm and should only be considered as a rudimentary way to grasp the potential that it provides.

Essentially, HailStorm is a Web-based service for storing and retrieving information. However, it's not just any sort of information that HailStorm is designed to manage, but specifically it is your information being stored for you. Think of the following related, but separate scenarios.

  1. You are on the road and need to check your calendar to see what meetings are planned for today. You find an Internet terminal and log into your Web-based calendar.
  2. You are on your home computer. The wallpaper on your desktop is automatically generated to include a small calendar in the corner, with birthdays and anniversaries that you had recorded in your Microsoft Outlook® (or other calendaring application) calendar.
  3. You are using your computer at work and have just installed a new application for helping you schedule the ride-share system that your company uses to encourage carpooling. Using it, you can coordinate your schedule with those of the others in your carpool.

Let's take a closer look at what exactly is going on in each of the above scenarios. In the first one, the same application is most likely being used, but on different computers, yet you still have access to your calendar. This is showing distributed/remote storage, and how you can get to your information from any location.

In the second scenario, we're showing how two separate applications are able to access the same calendar information in order to provide specifically different features. While a program like Outlook can provide a feature for generating desktop backgrounds with integrated calendars, it's a task better suited for a specialized application. And it would make a lot of sense for this second application to use an existing source of birthday and anniversary dates, rather than requiring the user to continually update the information in two (or more) applications.

In the third example, we are showing not only a sharing of information between multiple applications (Outlook and the Ride-Share application), but also showing how the information associated with multiple individuals can be rolled into an aggregated view for easier management.

All of these examples revolve around information being retained in a user-centric architecture, as opposed to an application-centric or device-centric architecture. The importance of this shift to a user-centric design is what empowers the user to have control over their data and information, while at the same time providing them with the flexibility and freedom to utilize this information in new ways.

Part of the objective of HailStorm is to provide a single data storage infrastructure that enables all three of these scenarios to work transparently across multiple applications, users, and even operating systems. Obviously, more than just calendar information needs to be integrated into such a solution. We are thinking through a variety of general purpose data stores that multiple applications could benefit from in this solution. In addition to a calendar, it would also include things like an inbox, contacts, profile, addresses, application settings, and more. Binding all of these together and providing a unique and secure key for accessing this information would be an Identity service through which the users manage their data, and through which applications request permission to interoperate with this data.

By providing a base set of general purpose data stores, it will allow applications to be designed that enable deeper, richer, and more unique capabilities. In scenario two above, if you were an application developer wanting to write such an application, you would either need to provide your own "important dates" database, or you would need to include a mechanism for importing and exporting dates from whatever scheduling system the user might be using. Building your own "important dates" database would be relatively simple, but of course it would also mean that most people would end up not keeping it updated because it is not where they are already storing their information, and they'd get tired of having to remember to enter it into your system. Writing import/export routines for several different scheduling programs would be more difficult because you'd have to deal with all of the peculiarities of how the data is being stored in each of them, and that would assume that the data format was one that was documented. So either way, it's not an easy solution.

A more elegant solution is for the users PIM/scheduling application and wallpaper/calendar application to use a common data store for interacting with the users information. This allows the user's schedule to be their schedule, and not the schedule of a particular application, thus making it easy for multiple applications to revolve around that same dataset, each adding their own value to it and increasing the overall value to the user.

There are, of course, numerous challenges and obstacles to overcome in order to provide all of this in a robust, secure, and easy to use format. It is also important that the underlying data schemas are laid out in a way that allows them to properly reflect the functionality that the vast majority of applications need them to provide. Over the next several months, you'll be seeing more information about HailStorm being made available in various mechanisms on MSDN Online. In the meantime, here are a couple of items to check out:

  • Press Release: HailStorm Announcement (March 19, 2001)
  • Demonstration: To see a demonstration of how Expedia.com might use "HailStorm" services on their Web site, check out this episode of the NET Show. Once the show starts, click on the Diversionary Tactics link to see Suzi LeVine's demonstration.

  
Show:
© 2014 Microsoft. All rights reserved.