Web services applications

New technology promises to smooth the way for BPI, EAI, and Web-based application development, but the work isn't done yet

When THE 2002 InfoWorld Web Services Applications Survey asked readers to name their top three goals for Web services, respondents cited business process integration (63 percent), application integration (58 percent), and Web-based application development (57 percent). Achieving these objectives will require more than an XML-enabled business Web that carries conversations made of SOAP messages among machines and applications. The modernization of EDI, left unfinished in the wake of the dot-com flameout, will finally go forward and wring vast inefficiencies out of b-to-b processes.

But where are the people in this mechanized utopia? They are the consumers of the goods and services that the system cranks out. More subtly, they are the touchpoints of the business Web. Consider the canonical Web services example, an XML-ized purchase order making its way through a purchase cycle. At each step, a person must apply the grease of human judgment that keeps the cogs turning. How that person interacts with the cloud of Web services is a crucial question that affects both Web services plumbing and application design.

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's purely SOAP-oriented API now stands Amazon'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 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 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 and Digital Harbor (see sidebar, "A new breed of smart desktop").

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'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.


Copyright © 2002 IDG Communications, Inc.