www.aspnews.com/analysis/analyst_cols/article.php/1414041

Back to Article

Weekly Review: Standards Make ASP Vision a Reality
By Phil Wainewright
July 16, 2002

As soon as ASPs first started making their applications available over the Internet, they encountered a stumbling block that has remained a barrier to adoption, even for their most enthusiastic customers.

Once a business has decided to start using Web-delivered applications, it's inevitable that it will want to combine several of them from different suppliers. But a lack of standards means there's no easy way of doing that, unless you go to a single provider for all of them — which defeats the object of getting them from the Internet in the first place.

Read and React
"Three-and-a-half years ago, in the first flush of the ASP boom, a dozen Internet-native ASPs banded together in a quest to establish standards that would enable their customers to combine Web-based services from multiple providers."

Give us your feedback in the ASPnews Discussion Forum

It's been a long journey but, in San Francisco this week, the foundations of a solution have at last started to emerge with the release of two important specifications that look set to become industry standards:

The primary achievement of these two specifications will be an accepted standards framework for single sign-on, which allows a user to move from one service to another without having to enter a separate user ID and password each time. Although that falls well short of fully automated service aggregation, it represents the culmination of more than three years' hard graft by a broad spectrum of vendors, and marks a significant milestone on the way to the ultimate objective.

Early ASPs Saw Needs for Standards
Three-and-a-half years ago, in the first flush of the ASP boom, a dozen Internet-native ASPs banded together in a quest to establish standards that would enable their customers to combine Web-based services from multiple providers.

Calling themselves Internet Business Service Providers (IBSPs), each member of the group specialized in a single class of application, including human resources management provider Employease, e-mail provider USA.NET, time management and invoicing provider Timebills.com (now known as professional services ASP OpenAir), and several others who ultimately failed to survive (see New Group Champions BSPs).

Subsequently joined by Web services aggregator Jamcracker, the group began mapping out the technology areas where standards would need to exist in order to achieve the ultimate ideal of seamless aggregation of multiple services. They found that, the more they looked at the proposition, the more complex it became.

Integrated access was just the starting point. Once users had logged in to a package of services from multiple providers, there would need to be agreement on how to handle billing, usage reporting and session management. There had to be standards for exchanging data, and for business process integration. The group decided to concentrate its efforts on the first step, and subsequently threw its weight behind SAML (Security Assertion Markup Language).

Three years later, SAML is finally due to become a formal standard for exchanging information about user identity and access rights. Meanwhile, the evolution of Web services has begun to fill in some of the other missing elements. At the same time, there's been a growing consciousness that too much prescription is sometimes a bad thing when defining standards for integrating multiple services.

Devil in the Details
The proposals from the Liberty Alliance illustrate the virtues of this latter point of view. The group could have gotten caught up in trying to devise standards that would cope with all the niceties of privacy, security and user autonomy that might crop up when exchanging identity and access information between providers. Instead, its 1.0 specification neatly sidesteps all of these issues by creating a unique code that allows two providers to recognize a shared user, without either of them having access to any of each other's information about that user (the user could even be registered under two completely different names).

This hands-off approach to aggregating services moves away from attempting to tightly integrate services with each other — which is where the IBSPs' efforts started to get bogged down in complex details — and instead allows them to join in a loose federation. What's interesting is that a federated approach still allows the user to exchange data and link up processes between multiple services, without tying the user into a hardwired relationship.

In other words, it's an approach that lets the user control the links and connections, rather than attempting to have the system do it all, and it's typical of the newly fashionable services-oriented way of thinking about computing, rather than the old systems-centric models. Although it requires a more open-ended architecture, it provides more choice and flexibility for users to create innovative solutions to their day-to-day business needs.

This is a development that many in the IBSP movement will gladly welcome. While researching this week's column, I looked at an article I wrote in April 2001, in which Chris Haddad, then chair of the group's technical committee and also engineering manager at Employease.com, warned against having too much of a focus on data integration: "The direction the industry should take is enabling business processes and enabling services around those business processes," he said. "People should start focusing on what processes they can enable for customers rather than how we can exchange data — not 'How does my legacy system think about data?' but 'How can we do this differently?'"

This week's announcements by SAML and the Liberty Alliance show that people have indeed begun to think differently. It's been a long and painful journey, but the barriers to adoption that defeated many of the early pioneers of Internet-based business services may finally, with the advent of Web services standards, be starting to come down.