Powerful Stuff: WS-*, Single Sign-On, and InfoCard

It's risky to speculate on the nature of the "powerful stuff" that Steve Ballmer mentioned during a Q&A session at the recent TiEcon 2005 conference:

"We are working on more existing powerful stuff around XML Web services that will address many issues beyond RSS."

However, a likely "powerful stuff" candidate is Microsoft's InfoCard initiative for personal digital identity management and Web-based single-sign-on (SSO) in the forthcoming Windows Longhorn client OS. The first public demonstration of InfoCard occurred in May at the Digital ID World 2005 conference in San Francisco. Microsoft more or less simultaneounsly published Kim Cameron's "The Laws of Identity" white paper and a more extensive "Microsoft's Vision for an Identity Metasystem" article. (Kim Cameron is Microsoft's Identity and Access Architect, and publishes the Identity Weblog). The "Pre-Release Software Code Named “Avalon” and “Indigo” Beta1 RC" download, which appeared on May 23, 2005, runs on Windows XP SP-2 or Windows 2003 Server. This download provides the Indigo runtime infrastrastructure for InfoCard Beta 1. (The only references to InfoCard Beta 1appear in the press release and the main Longhorn Developer page's link to the RC, which also has a link to the Release Notes.) Running the Indigo setup program installs the .NET Framework 2.0 April CTP (Beta 2) version. You also can download and install an updated WinFX SDK as an ISO image from a link on the download page. The runtime and SDK compatible with Visual Studio 2005 Beta 2. Johannes Ernst's Blog provides an independent overview of InfoCard and describes its reliance on the WS-* stack. According to Johannes, InfoCard employs the following WS-* members and related specs:

• SOAP [1.2]
• WS-Addressing
• WS-MetadataExchange
• WS-Policy
• WS-Security
• WS-SecurityPolicy
• WS-Transfer
• WS-Trust
• XML Signature
• XML Encryption
• SAML
• WS-Federation (?, unclear)

[Note that Indigo bindings for WS-* support use SOAP 1.2, which results in Web services that don't meet WS-I Basic Profile 1.1. As Tim Ewald observes, many organizations require that all Web services they publish or consume to claim BP-1.1 conformance.] If processing InfoCard identities requires implementation of the eight WS-* specs from the above list, support for SAML, and the Indigo messaging infrastructure, is InfoCard destined for HailStorm's fate? At this point, only WS-Security is an official OASIS specification; the remaining members are at varying points in the standards process. So far, InfoCard appears to me to be another example of the overly complex "everything at once" syndrome that doomed HailStorm. The preceding Indigo and InfoCard Beta 1 RC release followed a May 13, 2005 joint publication by Microsoft and Sun Micrososystems of the Web Single Sign-On Interoperability Profile and Web Single Sign-On Metadata Exchange Protocol (WSSOMEX) specifications. These specs provide a mechanism for integrating WS-* and Liberty Alliance identity management of Web-based single sign-on technologies. WSSOMEX represents Sun's first—if tentative—committment to the WS-* standards beyond WS-Security. The press release, transcript of remarks by Steve Ballmer and Scott McNealy's comments, and related links are here. WSSOMEX is the first concrete result of the 10-year Sun-Microsoft technical collaboration agreement of April 2004. Paul Madsen posted an early analysis of WSSOMEX and WS-MetadataExchange:

WSSOME[X] defines how WS-MetadataExchange can be used to determine which Single Sign-On protocol suites (SAML 1.1, ID-FF 1.2, SAML 2.0, WS-Federation, etc) your partner is capable of supporting so that the two of you can actually do something interesting (like enabling SSO for your customers, employees, etc). WS-MetadataExchange defines a SOAP-based request/response protocol. Fundamentally, one provider says to the other 'tell me what you can do'. If the returned list includes something that the asking provider can also [do], then we have an intersection of capabilities and we're off to the races. If [there's] no intersection, [there's] no way forward.

Sun's Hubert Le Van Gong posted a response to Paul's post and added his own initial InfoCard analysis and a follow-up in response to Kim Cameron's comments. InfoWorld's Jon Udell also weighed in with a post about Web single-sign-on with client-side certificates, a much simpler technology that never caught on, versus InfoCard. In fairness to InfoCard, the Liberty Alliance lists a large number of "Liberty-Enabled Products," but, according to Web service analyst Ron Schmelzer, "[T]here are still very few products, if any, that implement Liberty Alliance on the desktop client, and so Microsoft has a distinct advantage."

RSS and Web Services: Keep It Simple, Steve.

Amit Malhotra's May 19, 2005 post on therssweblog includes a transcript of his unscheduled Q&A session with Microsoft's Steve Ballmer at the TiEcon 2005 conference in Santa Clara:

Q1. How important is RSS? A fad, important, huge or will [it] replace the Web/HTML dominance of the internet? A1. We believe RSS is important and will be around for a while, but it is not going to change the world. It is a little too simple; that is also the reason everyone’s using it. We are working on more existing powerful stuff around XML Web services ... that will address many issues beyond RSS. RSS will be around, but whatever we are working next will be cooler and more prevelant. [Emphasis added] Having said that, there are groups in MS that believe RSS has the potential to change everything and many future technolog[ies] will be built around RSS, the internal debate goes on.

Q2. How do you, or do you, see Google/Blogger and similar tools being a threat to MS Office dominance? A2. Not at all, people will always need Office for the complexity of tasks they perform and, as such, Google’s offerings in the strain of Gmail/Blogger will not replace it. We think it will be part of what we offer in future versions of Office. Besides the next release of MS Office will have the tools to publish blogs as part of its collaborative tools; watch for them.

Amit's preceding transcript, to which I've made minor edits and emphasized text, generated a brief flurry of reaction by other well-known bloggers, including Microsoft's Robert Scoble, who left a comment to a related posting on Steve Rubel's Micropersuasion PR blog. A reader named Bud left the following comment that's a propos my preceding post on the issue of overcomplicating Web services and SOA:

When I talk to people who are doing web services and show them RSS, they say something like, "Hey, we could achieve a heck of a lot with just that. We should just implement it. Web services is so complicated and requires so much effort just to work." And, these are fairly sophisticated developers and architects. Simple, easy to implement technologies where developers can quickly do it and people can immediately see the value are going to win the day. That's things like AJAX as well as RSS.

Steve Ballmer's first answer indicates that Microsoft has a Web service-based replacement in mind for RSS that has a higher "coolness quotient," but I question whether any Web service API or toolkit can come close to competing with RSS's current prevelence in Web developer mindshare. [The assumption is that preceding references to RSS also encompass ATOM.] My bookshelf (as well as Don Box's) has a copy of the .NET My Services Specification (517 pp.) from the 2001 Microsoft Professional Developer Conference (PDC). .NET My Services, better known by its "HailStorm" codename, was intended to evelope XML-based identity, address-book, Web site favorites, calendar, travel and much other personal data with a digital wallet in a Web services wrapper. The essence of HailStorm, in the words of Mark Lucovsky, then Microsoft's Distinguished Engineer and Chief Software Architect of .NET My Services, was:

HailStorm embraced the idea of decoupling the data from the application. The idea was to allow a variety of applications to process and 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.

The HailStorm announcement aroused a call-to-arms among Microsoft's competitors to prevent Passport from becoming the world's default identity management and authentication protocol. The Liberty Alliance, championed by Sun Microsystems, proposed a "federated identity management system" and successfully thwarted serious consideration of Passport and HailStorm technology by IT management. Another issue with HailStorm was that client applications weren't really "simple." For example, the introductory chapter for the .NET Calendar service specificaton was 68 pages long. Lucovsky subsequently moved on to Google and recently posted a comparison of the core HailStorm concepts with those of RSS 2.0 and Atom. Mark cites the common core concepts as:

• Network Centric, Extensible Data Model, for Everyday Data
• Data Decoupled from Applications
• Anytime, Anyplace, and from Any Device Access
• Identity Centric Data Access

A major difference I see is that HailStorm proposed to standardize a wide range of data structures and methods for reading and updating personal information. HailStorm relied on the proprietary .NET Passport service (now "Passport Network") for authentication, which Microsoft's Kim Cameron now admits is out of context for authentication by non-Microsoft sites. As one commentor observed, HailStorm proposed to do "everything at once." RSS 2.0 and ATOM concentrate on public content sydication and have proven very successful at their assigned tasks, while only the successor of .NET My Alerts—SQL Server Notification Services—has achieved any semblance of industry adoption.

Microsoft Web Services DevChannel Opens at FTPOnline

Fawcette Technical Publications recently added a new Microsoft Web Services DevChannel to the FTPOnline portals collection. The DevChannel consists of links to Microsoft white papers, artlcles from FTP print and online publications, video clips from FTP conferences and MSDN TV, plus related resources. Service-Oriented Architecture (SOA) gets the primary emphasis, as expected, but many articles include sample C# and VB .NET Web service code. My "Build Real-Time Web Images" article from the August 2004 issue of Visual Studio Magazine was the lead link for the initial DevChannel page. The article describes how to write VB. NET 2003 Windows form clients for Microsoft's SQL Server-driven TerraService and MapPoint Web services. TerraService is an example of a set of freely-accessible Web services that enable .NET developers to display tiled aerial/satellite photographic images of most of the earth, and USGS topographic map images of North America. MapPoint Web services render bitmaps from vector-based maps of the U.S. and many other countries. Using MapPoint Web services requires obtaining a commercial or developer license and executing a simple username/password authentication request prior to invoking the desired Web method.

Update 6/14/2005: InfoWorld's Jon Udell commented on developers use of GoogleMaps versus TerraServer:

"Years ago an early reviewer of Visual Basic 1.0 (Steve Gibson, I think) said that VB increased the software developer's leverage by an order of magnitude. That was true, but you can't keep going back to the same well. In a column on Google Maps I wrote:

Developers haven't flocked to TerraServer. What's Google's secret? Web DNA and no Windows tax. Responding in email, Jim Gray reminded me that TerraServer does offer SOAP interfaces [1, 2]. And yet those interfaces demonstrably have not inspired a flurry of innovation. Why not? Microsoft is obliged to portray the Web-based user experience as a dead end that can never be improved, and Windows as the only way forward. So it's going to be Visual Basic and client/server all over again: Windows applications will control the user experience; servers will dish out the data; developers will connect the dots."

For a preview of the TerraService and MapPoint Web service client projects, check out the illustrated online help page on the OakLeaf Web site.

Like OakLeaf's public CFR Web services, the TerraService and MapPoint Web services take full advantage of Visual Studio's Add Web Reference Wizard to autogenerate .NET 1.0+ C# or VB .NET Web service proxy classes. Simplified programming of data-driven Web services and the capability to autogenerate Web service client proxy classes were Microsoft's primary marketing topics for .NET 1.0. VS 2005's new built-in Web server simplifies development and publication of basic SQAP 1.1 and 1.2 Web services, but offers few other Web service enhancements. SQL Server 2005 boasts the capability to host native (in-process) SOAP Web services that substitute Windows Server 2003's and Windows XP's built-in HTTP.sys driver for IIS and VS-generated .asmx files. Promotion of the WS-Security and other WS-* specifications, Web Services Enhancements (WSE) 2.0+, and the forthcoming Indigo message bus appears to have increased the FUD factor surrounding SOA in general and Web services in particular. This uncertainty has reduced IT management and developer interest in implementing basic .NET and Java Web services as the first step in demonstrating the practicality of enterprise-level SOA to corporate and line-of-business management. Perhaps the Web services developer community would be better served by more publicly accessible, data-intensive, real-world Web services and fully implemented client examples, such as the TerraService and MapPoint projects, rather than white papers that describe esoteric SOAP headers and emerging messaging "standards." RSS 2.0 and ATOM adhere to the Keep It Simple, Stupid (KISS) principal, which is the secret to their current success in content syndication. --rj