Don Box and HailStorm
The other day I stumbled on an interesting post by Don Box. In it, he discusses noticing his old HailStorm (a.k.a., ".Net My Services") reference manual. Don, I am not sure why that old book is in your living room? Mine is on a shelf in my basement, along with all my old .NET books...
Don's claim is that "the technology never saw the light of day". While it is true that Microsoft never shipped the system (at least not yet anyway), I wonder if others are successfully shipping the essence of HailStorm?
For the duration of this post, and for the entire comment stream, lets for a minute, forget the over-sensationalized past. Forget that Microsoft was involved in the design, development, and marketing of this system. Forget that many believed that Microsoft was attempting to associate HailStorm with a global identity system, and that some within Microsoft believed that Microsoft should house all of the data exposed by HailStorm in it's own data centers. I am asking you to put this behind you, and instead, lets just look at the essence of HailStorm, and decide if some of these ideas are shipping, or should be shipping.
As I look back on HailStorm, and try to distill it into some of its core concepts, I come up with the following list:
HailStorm was based on an XML data model. The system defined several core data types (calendar events, address book entries, bookmarks, profiles, etc.). Each core type had a set of required elements and attributes, and allowed for arbitrary extensions in both the element and attribute dimension, as long as those extensions are defined within a unique XML namespace. HailStorm had the notion of an <address/> type which defined a set of base properties associated with an address. Anyone could easily extend an address by including arbitrary, well formed XML from an arbitrary namespace. The data model was simple to use, simple to extend, and simple to process. There was no need to buy proprietary tools to crack, parse, manipulate, re-transmit, or re-purpose any type.
Looking at HailStorm through this facet, there are clear similarities between it, and RSS 2.0 and Atom. These two core systems are very powerful. Their ease of use, their simple extensibility, their inherent network centricity have unleashed many clever and useful applications.
Both of these systems specify a very simple container model, in both systems we see a variety of "everyday types including events, people and their properties, rich categorization, etc.
When Don claims that "the technology never saw the light of day", I agree with him that as a whole, HailStorm was never released, but that the essence of HailStorm, in this dimension is alive and well.
HailStorm embraced the idea of decoupling the data from the application. The idea was to allow a variety of applications to process an manipulate your calendar data, your address book, your email, your favorite web sites, your travel preferences and itineraries, etc. This is not a new, novel idea, but was certainly something that was important and core to the system. Simple applications that we were trying to enable included the ability to overlay your personal calendar with the calendar of your favorite band, or your favorite sports team, or your spouse, etc. We wanted to enable a unified "address book" where your contacts could be used across applications written by any vendor.
In keeping with our RSS/Atom theme, I wonder if these two systems have similar goals? Isn't it true that we all love this idea of decoupling data from applications? That we are able to use applications like bloglines, newsgator, or a host of other aggregators/notifiers to keep track and reuse all that is going on out there? What would the blogsphere be like without this technology? What would it be like if you could only read blogger blogs on blogspot? Or read Don's stuff on pluralsight? Or read Jon Udell on infoworld? I think that we can all agree that this theme that was central to the vision of HailStorm is extremely valuable, and has certainly "seen the light of day". In fact, I think we can all also agree that we would rather see more information work like this...
HailStorm embraced the idea of accessing your data anytime, anywhere, and from any device. In fact, during our first public demonstration of the system, we showed read/write HailStorm access from:
I don't remember if we demonstrated Windows access from .NET, but for sure, that would have worked too.
In our system, if you had a crude XML parser, and if you had an ability to send/receive HTTP, you could interact with HailStorm. We did not force you to purchase any special tools, install complex DLL's or type libraries, generate proxy classes through a WSDL parser, etc. HailStorm was based on an approachable protocol that was easy to understand and use from any platform and from any device.
Looking at both Atom publishing protocol for updates, and A9's OpenSearch API for query is an interesting excercise. These systems all are designed to provide an approachable, read/write API that will work from any network capable device, without the need for a proprietary runtime or tool suite. These systems put you, the developer first. I would argue, and I think most of you would agree, that uniform access, any time, any place, and from any device, independent of any proprietary runtime stack is exactly what it takes for an information access protocol to succeed. Has this technology shipped? For sure, in pockets of the broader industry, this approach is thriving. In other areas, the illusion of openness is there, but the reality is that expensive and complex proprietary tools act as your gateway...
The final facet of HailStorm, is the idea of identity centric information access. In HailStorm, the model was based on an identity space where an identity could represent a person, an organization, a group, etc. Given an identity, you could determine where to send messages to interact what information related to that identity. Both the identity space and the services bound to that identity were fully federated. We did this so for instance, the calendar information for Callie could be served by servers at Microsoft, Yahoo, Google, etc. So that the travel data for Nikki could be served by Expedia, American Express, or Cisco... Our system was based on a discoverable, distributed directory known as the myServices service designed to answer these simple queries.
Architecturally, HailStorm provided a level playing field where service providers could compete for a customer's business, and where because of all the facets listed above, a customer had complete freedom to move from provider to provider, with no impact on applications running on her behalf.
Let us look back one more time on the central concepts, or the essence of HailStorm:
I believe that there are systems out there today that are based in large part on a similar set of core concepts. My feeling is that the various RSS/Atom based systems share these core concepts and are therefore very similar, and more importantly, that a vibrant, open and accessible, developer friendly eco-system is forming around these systems...
Don's claim is that "the technology never saw the light of day". While it is true that Microsoft never shipped the system (at least not yet anyway), I wonder if others are successfully shipping the essence of HailStorm?
For the duration of this post, and for the entire comment stream, lets for a minute, forget the over-sensationalized past. Forget that Microsoft was involved in the design, development, and marketing of this system. Forget that many believed that Microsoft was attempting to associate HailStorm with a global identity system, and that some within Microsoft believed that Microsoft should house all of the data exposed by HailStorm in it's own data centers. I am asking you to put this behind you, and instead, lets just look at the essence of HailStorm, and decide if some of these ideas are shipping, or should be shipping.
As I look back on HailStorm, and try to distill it into some of its core concepts, I come up with the following list:
- Network Centric, Extensible Data Model, for Everyday Data
- Data Decoupled from Applications
- Anytime, Anyplace, and from Any Device Access
- Identity Centric Data Access
HailStorm was based on an XML data model. The system defined several core data types (calendar events, address book entries, bookmarks, profiles, etc.). Each core type had a set of required elements and attributes, and allowed for arbitrary extensions in both the element and attribute dimension, as long as those extensions are defined within a unique XML namespace. HailStorm had the notion of an <address/> type which defined a set of base properties associated with an address. Anyone could easily extend an address by including arbitrary, well formed XML from an arbitrary namespace. The data model was simple to use, simple to extend, and simple to process. There was no need to buy proprietary tools to crack, parse, manipulate, re-transmit, or re-purpose any type.
Looking at HailStorm through this facet, there are clear similarities between it, and RSS 2.0 and Atom. These two core systems are very powerful. Their ease of use, their simple extensibility, their inherent network centricity have unleashed many clever and useful applications.
Both of these systems specify a very simple container model, in both systems we see a variety of "everyday types including events, people and their properties, rich categorization, etc.
When Don claims that "the technology never saw the light of day", I agree with him that as a whole, HailStorm was never released, but that the essence of HailStorm, in this dimension is alive and well.
HailStorm embraced the idea of decoupling the data from the application. The idea was to allow a variety of applications to process an manipulate your calendar data, your address book, your email, your favorite web sites, your travel preferences and itineraries, etc. This is not a new, novel idea, but was certainly something that was important and core to the system. Simple applications that we were trying to enable included the ability to overlay your personal calendar with the calendar of your favorite band, or your favorite sports team, or your spouse, etc. We wanted to enable a unified "address book" where your contacts could be used across applications written by any vendor.
In keeping with our RSS/Atom theme, I wonder if these two systems have similar goals? Isn't it true that we all love this idea of decoupling data from applications? That we are able to use applications like bloglines, newsgator, or a host of other aggregators/notifiers to keep track and reuse all that is going on out there? What would the blogsphere be like without this technology? What would it be like if you could only read blogger blogs on blogspot? Or read Don's stuff on pluralsight? Or read Jon Udell on infoworld? I think that we can all agree that this theme that was central to the vision of HailStorm is extremely valuable, and has certainly "seen the light of day". In fact, I think we can all also agree that we would rather see more information work like this...
HailStorm embraced the idea of accessing your data anytime, anywhere, and from any device. In fact, during our first public demonstration of the system, we showed read/write HailStorm access from:
- Solaris written in Java
- Linux written in perl
- Windows written in perl, javascript, C
- Palm VII (written in I forget, sorry, I think C)
I don't remember if we demonstrated Windows access from .NET, but for sure, that would have worked too.
In our system, if you had a crude XML parser, and if you had an ability to send/receive HTTP, you could interact with HailStorm. We did not force you to purchase any special tools, install complex DLL's or type libraries, generate proxy classes through a WSDL parser, etc. HailStorm was based on an approachable protocol that was easy to understand and use from any platform and from any device.
Looking at both Atom publishing protocol for updates, and A9's OpenSearch API for query is an interesting excercise. These systems all are designed to provide an approachable, read/write API that will work from any network capable device, without the need for a proprietary runtime or tool suite. These systems put you, the developer first. I would argue, and I think most of you would agree, that uniform access, any time, any place, and from any device, independent of any proprietary runtime stack is exactly what it takes for an information access protocol to succeed. Has this technology shipped? For sure, in pockets of the broader industry, this approach is thriving. In other areas, the illusion of openness is there, but the reality is that expensive and complex proprietary tools act as your gateway...
The final facet of HailStorm, is the idea of identity centric information access. In HailStorm, the model was based on an identity space where an identity could represent a person, an organization, a group, etc. Given an identity, you could determine where to send messages to interact what information related to that identity. Both the identity space and the services bound to that identity were fully federated. We did this so for instance, the calendar information for Callie could be served by servers at Microsoft, Yahoo, Google, etc. So that the travel data for Nikki could be served by Expedia, American Express, or Cisco... Our system was based on a discoverable, distributed directory known as the myServices service designed to answer these simple queries.
Architecturally, HailStorm provided a level playing field where service providers could compete for a customer's business, and where because of all the facets listed above, a customer had complete freedom to move from provider to provider, with no impact on applications running on her behalf.
Let us look back one more time on the central concepts, or the essence of HailStorm:
- Network Centric, Extensible Data Model, for Everyday Data
- Data Decoupled from Applications
- Anytime, Anyplace, and from Any Device Access
- Identity Centric Data Access
I believe that there are systems out there today that are based in large part on a similar set of core concepts. My feeling is that the various RSS/Atom based systems share these core concepts and are therefore very similar, and more importantly, that a vibrant, open and accessible, developer friendly eco-system is forming around these systems...
posted by Mark Lucovsky, Software Engineer at 5:43 PM
32 Comments:
I don't remember if we demonstrated Windows access from .NET, but for sure, that would have worked too.
Yes Mark, we did show a .NET version of this in the demos. We had a stripped-down "native" version and a class library on top of it.
FWIW it sure seems like RSS + Atom + Script + GMail perhaps sure feels an awful lot like HS.
OK, Thanks for reminding me paul. We did do a .NET version as well. How corporate of us :)
Interesting that you see the same similarities that I see...
Oh, and now dodgeball for MyAlerts/MyPresence? Also an SMS presence we never did quite figure out in HS. When do I get my Google calendar?
Don't forget the macos x/freebsd version of the demo. :)
I think you are underestimating your effort at Hailstorm. The key, at least to me, would be the common storage of everyday data in a non-application-specific way.
It has not happened yet. It is extremely important -- the biggest thing I can think of happening to software since at least the seventies -- and pushing its adoption is an enormous undertaking. We will have schema wars, but once you get common data models for everyday items that are extensible, and pressure for common data models for more domain specific data, we can really begin to do some interesting things.
Yes, it looks a little bit like RSS+ATOM+Script+GMail, but only when every viable application is working with the same cloud of data does the beauty really come out.
Oh, we did ship the Alerts stuff -- MSN Alerts (and .NET Alerts) was just about the only service we actually "finished" of Hailstorm and continued to ship. It's a webservice that outside agencies were able to tie to.
You say that to you, the key was the common storage of the every day data. I agree with your thinking at the highest possible level, BUT thinking in terms of common storage, when you really mean common storage is the fatal mistake that Microsoft continues to make in this space. Instead, it is much better, in my opinion, to take your same line of thinking and say that the key is common access to the everyday data. Know what I mean here?
If we had this, and IF the access mechanism was approachable, used the common data model, was designed for the network, etc., this would provide us all with the illusion of a common storage layer without forcing the cost and complexity, world wide grand unification of storage, etc.
The HSDL protocol where we specified exactly this type of information access layer was a shot at this... I see some of the emerging work in A9's open search protocol as an attempt at query unification, and in Atom's publishing API as an attempt in the update side. Given that both of these work within the framework of the Atom and RSS data and container models, I think we are moving in a good direction.
Contrast this approach with the approach taken by Microsoft with the WinFS project where the sole focus has been on unification of the actual bits being stored, a complimentary and proprietary data model, and a .NET centric proprietary API. This is something that is very difficult to pull off, and we can perhaps assume that it is because of this difficulty that Microsoft was forced to remove this key component from Longhorn?
Mark,
First of all, let me just say that I think it is pretty damn cool that the architect of Hailstorm is so accesible here, and I think RSS is in a lot of ways responsible for that.
I agree that it is common access, not common storage. The big problem is getting the whole ball rolling, and perhaps a simplified, easy approach is the best way to do that. Perhaps a clear thinking behemoth like google or MS can do the heavy lifting. I do not know the answer.
Focusing on common access, you run into a directory problem, and it is very hard to guarantee that every action hits every piece of data that it is supposed to. It is a very big undertaking. I think it is unclear how it will shakeout, but I think MS attempts on the client and LAN wil be helpful to the other aspects of getting the common access to everyday data ball rolling, and when it happens we will see something kind of like what was being hyped with the dot com stuff.
Mark,
Even though you are the author of these ideas, they are intellectual property of MS. As an ex employee of MS, you should be discrete about unpublished IP materials from an ex-employer.
> This is something that is very difficult to pull off, and we can perhaps assume that it is because of this difficulty that Microsoft was forced to remove this key component from Longhorn?
I think WinFS was implemented in managed code - it was too slow.
They are reimplementing it in C.
"As an ex employee of MS, you should be discrete about unpublished IP materials from an ex-employer."
Everything we have discussed in this thread has been Published in the form of freely available books, widely read press articles, and Microsoft's own public web site. This thread contains absolutely NO unpublished IP.
Don started this topic when he stumbled on his old .NET My Services book which describes all of the Schemas, the Principles of Operation, the directory scheme, the security model, and the HSDL access layer.
A similar level of detail is available on MSDN describing WinFS from a developers perspective. Take a look at WinFS A Developers Perspective
This post has been removed by a blog administrator.
Sorry about those comments from chaudes. Looks like its been taken care of.
I wonder if others are successfully shipping the essence of HailStorm?
You have a very valid point here. Hailstorm was no rocket science, but it was trying to be everything at once. I also remember how hard it was to push back on that HS thing that nobody has ever even seen and more importantly couldn't see what it practically did.
So others are building it by patching bits and pieces instead. Google is in the read stage with RSS with releasing everything RSS planned in a couple of weeks. When Google moves into the write stage ... it will become Hailstorm. Are they building an operating system?! :)
"The .NET My Services MyServices service serves as a directory service to find other .NET My Services services". :-) Our choice of marketing names certainly didn't help advance the cause of this promising technology either. Good write up Mark...
Before there was Hailstorm, there were companies like Yodlee. As early as 1999, Yodlee naively made efforts to get big (mostly financial) companies to migrate existing datafeeds to use standard XML. Their problem, of course, is that they were working with big companies, and although it is not said often enough, any real progress will never be made by big companies but are generally grassroots efforts.
.net alerts did not really take off that well
a - required passport
b - run by MSN
c - too much outsourced service elements (which have recently been absorbed)
d - did i say required passport and run by MSN?
Ok I don't get it. The network centric open standards stuff not tied to a proprietary stack I can understand. But where's the data model? Where's the federated identity?
federation only works .. well it doesnt
OASIS can't even agree on basic schema or it's scope.
At the end of the day you can do alot more for less. Overloaded encapsulation is heavy lifting that could be moved to other components of the stack.
If the information offered needs to be paid for, then the web services movement grinds to a halt.
I can't even do a Google web search via web services. They have an API but there's limited usage for each token last I checked. Even RSS is often just teasers for the full article (with ads).
Web services have business problems. When you find a way to sell them profitably I'll tip my hat to you.
Hi Mark,
We work quite a bit with salesforce.com. Many aspects of their sforce architecture remind me of Hailstorm. They have the closets thing I've found to a service enabled developer platform these days.
Best,
Bill Appleton
CTO
DreamFactory Software
billappleton@dreamfactory.com
This post has been removed by a blog administrator.
This post has been removed by a blog administrator.
This post has been removed by a blog administrator.
This post has been removed by a blog administrator.
As the first dev hire for Hailstorm I did most of the demos shown at Hailstorm's first SDR.
The original demo for the Palm VII device was written in C using CodeWarrior.
It was a poor performer as I recall due to the poor bandwidth of the device, WAP gateway, and various encoding tricks we had to do just to get an http post outside of Palm's service infrastructure.
I believe there's a quote here I'm forgetting that caused a little bit of controversy at the time.
I'm afraid that Microsoft's need to have central control around both file-formats, file-transfer, and ultimately the source-code will lead to their ultimate downfall.
The people at google are on the right track. Sure, they aren't 100% open source, but they also aren't using a monopoly to exploit the masses with expensive, poorly designed software.
There is just something about the OpenSource community, that keeps it from designing poorly made, "clunky," or otherwise innefficient software. This "Something" just isn't something that the great people at "Micro$oft" can understand, fathom, or realize, and it seems (From your description) to be the creation of projects such as Hailstorm.
Maybe it just is me, but the moment Google releases an OS, I'll guarentee you that I'll begin reformatting my HDD to install it, becuase I can vouch for their creativity, effectiveness, and metaphorical "Agility."
We will feel that all our efforts put into this writing about data have not gone to vain if you get some benefit from reading it. Do wish you were benefited.
nice site for more books I have some more gifts..
Reference books
Books
Kitaben
books
knowledge
liberary
Reference Books
tutorials
rapidshare tutorials
rapidshare books
MZWorld
Upload Books
MZWorld Library
Books Forum
Hi,
This article is good and informative.
Software Development Company
These articles are fantastic; the information you show us is interesting for everybody and is really good written. It’s just great!! Do you want to know something more? Read it...:Great investment opportunity in Costa Rica: condos resort, destin beach, destin condos. Visit us for more info at: http://www.jaco-bay.com/
black mold exposureblack mold symptoms of exposurewrought iron garden gatesiron garden gates find them herefine thin hair hairstylessearch hair styles for fine thin hairnight vision binocularsbuy night vision binocularslipitor reactionslipitor allergic reactionsluxury beach resort in the philippines
afordable beach resorts in the philippineshomeopathy for eczema.baby eczema.save big with great mineral makeup bargainsmineral makeup wholesalersprodam iphone Apple prodam iphone prahacect iphone manualmanual for P 168 iphonefero 52 binocularsnight vision Fero 52 binocularsThe best night vision binoculars here
night vision binoculars bargainsfree photo albums computer programsfree software to make photo albumsfree tax formsprintable tax forms for free craftmatic air bedcraftmatic air bed adjustable info hereboyd air bedboyd night air bed lowest pricefind air beds in wisconsinbest air beds in wisconsincloud air beds
best cloud inflatable air bedssealy air beds portableportables air bedsrv luggage racksaluminum made rv luggage racksair bed raisedbest form raised air bedsaircraft support equipmentsbest support equipments for aircraftsbed air informercialsbest informercials bed airmattress sized air beds
bestair bed mattress antique doorknobsantique doorknob identification tipsdvd player troubleshootingtroubleshooting with the dvd playerflat panel television lcd vs plasmaflat panel lcd television versus plasma pic the bestThe causes of economic recessionwhat are the causes of economic recessionadjustable bed air foam The best bed air foam
hoof prints antique equestrian printsantique hoof prints equestrian printsBuy air bedadjustablebuy the best adjustable air bedsair beds canadian storesCanadian stores for air beds
migraine causemigraine treatments floridaflorida headache clinicdrying dessicantair drying dessicantdessicant air dryerpediatric asthmaasthma specialistasthma children specialistcarpet cleaning dallas txcarpet cleaners dallascarpet cleaning dallas
Post a Comment
<< Home