OASIS approves a Web services standard that could ease 'mash-ups'

Must every spreadsheet you ever use until the end of recorded time be an "Excel spreadsheet?" A protocol for making functional data more versatile for Web portals, so users can choose their own tools, is taking its next evolutionary step.

The definition of "portal" with regard to the Web changes by the year; and while sites such as Yahoo would like for it to still be somewhat synonymous with "home page," today, Web services engineers use the term to mean some central location where Web services can be used collectively. And though sites such as Google have tried to instantiate that vision by making JavaScript widgets collectible together through pages such as iGoogle, Web engineers today have a more functional vision in mind: They see the next "portal" as the network-empowered equivalent of yesterday's "desktop."

Imagine everything you do now on a desktop -- word processing, watching videos, gaming, balancing the checkbook -- facilitated through a central portal that provides immediate access to the latest software from multiple providers. You don't install the software; you just register for it and use it. That's the vision Web engineers perceive today.

Two protocols have done more to bring about that vision than any one piece of software: SOAP (whose acronym IBM has recently re-phrased as "Services-Oriented Access Protocol") and REST (Representational State Transfer). Both use very different models for making services available through the Web, though both have much the same purpose: facilitating the throughput of data using request/response lexicons.

Up until recently, the approach engineers have taken to the question of how data transferred over Web services should be presented, is to embed presentation markup in the data. That's what HTML is for after all, isn't it? The typical approach to data used in Web services is that data is typed to match the application that best handles it, like assigning MIME types to data shared through Internet packets. If it's an image, then the software registered for handling images should take care of it; if it's a Web page, then the Web browser should be capable of parsing the markup and laying out the page properly.

But that approach falls short of perfect in today's model of the "portal," which is becoming less dependent on embedding code within HTML, and more apt to experiment with managed code components like Flash, Silverlight, .NET, and that Java thing you read so much about. In a Web usage model that sheds its reliance upon the browser to delegate authority to other installed applications, how should presentation data be handled; how should a portal show you a spreadsheet, for instance, that behaves the way its authors intended?

The OASIS standards agency has been tackling that very problem for the past few years, and this morning announced it's ready to adopt a new approach to Web services that's been heavily championed by IBM: It's called Web Services for Remote Portlets (WSRP), whose version 2.0 is now being adopted as an OASIS standard.

"Portals and other Web applications render and aggregate information from different sources and provide it in a compact and easily consumable form to End-Users," reads an excerpt from the WSRP 2.0 specification (PDF available here). "Among typical sources of information are web services. Traditional data-oriented web services, however, require aggregating applications to provide specific presentation logic for each of these web services. Furthermore, each aggregating application communicates with each web service via its unique interface. This approach is not well suited to dynamic integration of business applications and content as a plug-and-play solution."

Or to put it another way...With an ordinary Web application that uses REST or SOAP to obtain data, oftentimes data is all it gets -- pretty flat and ordinary. As a result, the applications which handle that data do so in their own way -- more importantly, in a way not prescribed by the author of the data. So when you're trying to craft a unique Web application, you build the style of that application into the program rather than the data. So much for embedding HTML in the data and having the browser solve it that way.

WSRP's approach to the situation isolates four key "actors" in the Web application process: the end user, the portlet which the user is directly operating, the consumer which is the thing (not the user) that asks for and receives data, and the producer which is the remote entity responsible for generating the data. The SOAP- or REST-like transactions take place between the consumer and producer, so that part of the process isn't kicked over in upheaval. But then a new set of protocols for how the user receives and then interacts with that data, determines how the portlet presents the data.

Also under such a system, as IBM's documentation explains, the portlet may already have answers on-hand for how data is displayed. Perhaps the end user already has a widget in place for such an operation, such as displaying a stock quote.

As Booz Allen Hamilton consultant Bryan Castle wrote in 2005 for WSRP 1.0, "With WSRP in the mix, you could much more easily integrate a stock quote portlet into your portal. You could browse the UDDI directory for portlets themselves or alternatively provide end-users with the ability to browse a registry of portlets. Once the Stock Quote Portlet has been discovered, the process of adding it to the portal takes just a few clicks of the mouse and you are done. You don't need to perform any custom coding or deployment activities since the portlet is being consumed through WSRP. The end-user doesn't need to understand anything about WSRP or even that their portlet is actually being hosted by a remote producer! The end-user only knows that they have a directory of available portlets from which they can pick and choose. What could be easier?"

The first demos of the fully standardized WSRP 2.0 in action will likely involve "mash-ups" representing user-configured widget pages -- Web-based desktops, if you will -- showing Web services consumed in manners both determined by the producer and by the portlet. Oracle and Vignette were also among the major sponsors behind WSRP 2.0's adoption.