Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
For me, having to remember dozens of Website usernames and passwords surely surpasses all other inconveniences. Whether you wish to chat on JavaWorld's forums or keep up with the news on your favorite current affairs Website, chances are you will be asked at some point to enter your username and password. Following closely behind that aggravation are the bothersome HTML forms you must fill out to obtain your user IDs in the first place.
Username and password boxes are annoying because they present an experience without close parallel in the off-line world. When returning home after a long day's work, once you unlock your front door, you can freely move about without identifying yourself to your kitchen appliances, your bathtub, or the television set. Inside your home, you gain complete access even to your checkbook without that checkbook asking for a username and password.
Even offices work similarly. Once you are permitted to enter an office building, you can typically move about without having to be reauthenticated to grab a cup of java from the lunch room or to drop by your coworker's cubicle for a quick chat. Homes and offices, in effect, are circles of trust: once admitted inside those circles, you are mostly free to go about your business.
Currently, the Web is a seascape of myriad user account islands, and Websites fail to share users' preferences. Even if you have already specified on an airline's Website that you're a vegetarian, chances are, the hotel where you'll be staying will ask for your meal preferences again. If you have children, you currently must separately specify that fact to hotels, restaurants, travel agencies, cruise lines, amusement parks, insurance companies, and the like. Next to usernames, passwords, and personal information request forms, isolated user preferences stand high on my list of awkward Web user experiences.
The Liberty Alliance Project specifications offer a possible solution to the first two of those limitations. The next-generation Liberty specifications, version 2.0 due in a few months, hope to solve the third one as well. What represents a mere inconvenience for Websites may well be a showstopper for Web services. You can almost always count on a human to punch her username and password into a Web browser. But Web services do not enjoy the benefits of human supervision: they must often invoke other Web services on their own. Even if Web services execute on behalf of a human user, they can't stop and fetch their anthropomorphic master for user access information. Rather, either they must have a way to obtain access information automatically or Web services acting together to support a common goal must trust one another prior to service-to-service invocations.
Liberty addresses the needs of both existing Websites and Web services. In this article, I first introduce the specific problems that Liberty tries to solve and the solutions it proposes. Then I describe an open source Liberty implementation, the Interoperability Prototype for Liberty (IPL), and implement a simple Liberty-enabled system using IPL. That example will feature a traditional Website infrastructure, allowing you to sign on once and gain access to two Websites. The example is easy to extend to Web services.