The browser is today, and will for some time remain, the dominant way to interact with Web services on the desktop. More accurately it's a platform that supports many different modes of interaction. Cloud-based SOAP clients can reflect data into the browser as HTML. The browser can host Java, ActiveX, Flash, or other kinds of components that make SOAP calls; or the browser itself can make SOAP calls using its built-in script engine. The browser can also suck in raw XML data and process it locally, perhaps even while offline, using built-in parsing and transformation engines.
As a broader definition of Web services takes hold, the browser's role may solidify even more. SOAP is morphing from an RPC (Remote Procedure Call) protocol into a general document exchange protocol. The schism that had divided the SOAP and REST (Representation State Transfer) architectural styles has narrowed. Alongside Google Inc.'s purely SOAP-oriented API now stands Amazon.com Inc.'s hybrid API; it responds to SOAP calls but also supports standard Web URLs that route queries through server-side XSLT (Extensible Stylesheet Language Transformation) to produce vanilla XML or HTML results.
It's no surprise that 76 percent of survey respondents cited the browser as their dominant Web-services client platform for the next 12 months, which is more than twice the number who cited the second most popular choice, Win32. Still, the limitations of the browser are well-known, and it has been under attack for some time. As a universal client, the browser is a jack of many trades but master of none. Its page-refresh model thwarts two major goals: context-preserving user interfaces and real-time, two-way communication. A diverse array of products is now emerging that aims to achieve one or both of these goals.
Clearly, Microsoft Corp.'s Office will be one of the better-known faces of the business Web. As proof, 35 percent of survey respondents plan to consume Web services from Office applications during the next year. The Office Web Services Toolkit -- which debuted in January and was updated last month with support for complex SOAP data types -- helps VBA (Visual Basic for Applications) developers invoke Web services from Excel, Word, or Outlook. The toolkit, for XP only, recreates Visual Studio .Net's headline feature in the Office IDE: A developer can acquire a reference to a Web-based WSDL file, add it to a project, auto-generate the proxy code needed to access the WSDL-described services, and then use IntelliSense to latch onto the names of those services while writing VBA code.
It's tempting to write this off as nothing special. The easy access to Web services that Visual Studio .Net pioneered has quickly become a commodity. And if Office were destined to become a universal foundation for customized applications, years of Microsoft evangelism should already have made it so.
Nevertheless, the toolkit opens up important new vistas. Word documents that look up and insert ZIP codes or Excel spreadsheets that talk directly to government tax tables are humble examples. But when you multiply them a thousandfold, a difference of degree becomes a difference of kind, and a meaning of "software as a service" begins to emerge. If neither the browser nor the Office suite can deliver the ultimate human interface to the business Web, then what can? There are lots of ways to skin the cat. Since Microsoft won the browser war, its flavor of dynamic HTML has become the de facto standard for some developers. Java, which was originally positioned as a UI technology but found more traction in the cloud, may yet stake its claim on the desktop thanks to faster processors, fatter pipes, streaming deployment, and access to Web services.
Macromedia Inc. has positioned Flash as a lightweight, high-performance, media-savvy, and scriptable alternative to client-side Java. Microsoft, of course, has .Net waiting in the wings. The CLR (Common Language Run time) and .Net framework, when they become standard on the Windows desktop, will clean up a mess of Windows APIs and promote a new breed of rich, services-aware client apps. Survey respondents reported that all these options are in play. Finally, there's a new crop of XML-driven user-interface technologies from companies such as Altio Inc. and Digital Harbor.
But connecting people to the business Web requires more than just effective presentation styles -- new communication styles are needed, too. Kenamea's "application network," KnowNow's "application-layer internetworking," and Macromedia Inc.'s Flash Communication Server MX are prototypes of a messaging architecture that drive services to the desktop; they are implementations of a general style that does not have a standard associated with it yet. Strategies common to all three include store-and-forward messaging, event routing, publish/subscribe notification, data caching in the cloud and on the desktop, and APIs to create "digital dashboard" applications that leverage these capabilities.
These innovations bode well for Web services integration, but they push beyond current standards. Although quite a few legacy assets are exposed as Web services and available for integration, IT leaders would rather wait for the dust to settle. Citing incomplete or nonexistent standards, only 12 percent of respondents are confident that Web services can deliver the desired levels of integration within the next 12 months; but the figure rises to 49 percent over a three-year period. A business Web that's built around human touch-points may not be right around the corner, but it's visible on the horizon.
A new breed of smart desktop
When programmers learn to wrap SOAP envelopes around legacy protocols and build new software using a services-oriented architecture, new challenges arise. How do they deliver these services and empower people to use them effectively?
The browser makes a poor digital dashboard. SOAP-enabled Office, Win32, Java, .Net, and Flash clients can be more effective, and these avenues are being explored. Also, vendors such as Altio, Digital Harbor, and Fourbit are pioneering a new kind of "smart-client" technology: A Java-based run time, deployed to the desktop, fetches XML descriptions from the network and renders them as interactive GUI applications with widgets that talk locally to one another and remotely to Web services. Because they are purely XML-driven, the Java rendering engine could (with some elbow grease) be replaced with a .Net (or other) renderer.
The three technologies -- Altio's AltioLive, Digital Harbor's PiiE (Professional Interactive Information Environment), and Fourbit Group Inc.'s Fablet -- use XML not only to describe application behavior and local/remote componentry, but also to normalize data drawn from disparate sources into a common pool that can be locally sorted, queried, and stored. Each uses a proprietary storage scheme, but all are well-positioned to use -- and could help drive the market for -- embedded XML databases.
All three include GUI toolkits tuned for the construction of applications that search, display, and interact with complex data, including tables, records, and images. AltioLive features native controls for categorizing and grouping data; basic multidimensional analysis is a core feature of the platform. With PiiE, users can create hyperlinks that query components so that, for example, clicking on a name will simultaneously find a map in a GIS (Geographic Information System) widget and an address in a directory widget.
These platforms abstract away the details of GUI construction and encourage developers and users to focus on information architecture. That's exactly the right approach. XML, after all, is not simply a universal messaging format. When the Web services plumbing is in place, the real endgame comes into view: contextualizing information so that people can immediately understand and act on it.
These smart-client technologies can reduce the programming burden, but IT must still embrace XML data management disciplines to make the most of the opportunity. Our survey shows that's happening: 23 percent of respondents deploy XML-based applications, 14 percent are building with XML, and 19 percent plan to do so within the next year.
THE BOTTOM LINE
Web services applications
Executive Summary: Business process integration and application integration are the top goals for Web services, but first Web services must cross the last mile to the desktop. Our survey shows that a broad mix of client-side technologies is preparing to meet the need.
Test Center Perspective: The browser remains the dominant Web services client, but there is a growing demand for context-preserving user interfaces and real-time two-way communication. Early solutions show promising innovation, but they push ahead of standards. For now, survey respondents are watching and waiting.