Accessing web-services - Storage Management

Computer Technology Review, Feb, 2003 by Bruce Grant, Dave Mitchell, Scott Lemon

Transferring the power of the desktop into an Internet browser environment is the essence of Web services. According to the META Group, "During the next 2-3 years, most packaged business applications and newer custom applications will have fairly complete event-driven interfaces that will be exposed via the Web services model, and Web services creation capability will be an automated part of virtually all development environments."

Today's Web service technologies are being specifically designed to enhance the Internet strategies of the enterprise. The promise of Web Services is to allow enterprise-level computing with suppliers, partners and customers in a powerful, familiar and easy-to-use medium. With Web applications built on the Web services model, important business contacts can simply access enterprise Web applications the same way they would any other Web site. Once there, they'll then be treated to a dynamic user experience that mirrors a traditional desktop-computing environment--or will they? In the Web Services creation process, today's IT professionals are struggling to determine the most appropriate method of accessing Web Services and creating usable Web applications. Currently, the three primary choices include:

1. HTML-based Delivery

2. Applet and Plug-in Delivery

3. "Rich-thin Client" Delivery

HTML: The Road Less Traveled

HTML alone is incapable of delivering usable Web applications or directly accessing a Web Service. Browser application technologies have evolved significantly since their inception. Originally, the government and educational institutions designed the Web to share "linked" documents. The Web was never intended to handle the complexities of enterprise computing and business processing as an application platform. HTML forms were the earliest Web applications to appear--providing a limited set of crude user interface components. Because of their underlying structure, HTML forms forced users to navigate through a series of independent Web pages to accomplish the simplest of tasks. Unfortunately, they delivered a halting, frustrating and nonintuitive user experience--costing businesses in lost customers and reduced productivity. Even today, industry vendors are struggling to create Web applications that can successfully deliver dynamic back-end content as sophisticated, front-end presentation using HTML. Even with the advancements in browser technologies, HTML alone simply isn't robust enough to handle the complexities of real-world enterprise computing in a Web Services model.

Inconsistencies and inefficiencies of HTML-based Web applications are both costly and limiting for most enterprises. Early adopters recognized that most end-users were paralyzed by the unfamiliar interface provided by Web applications built on HTML. Because first-generation Web applications relied solely on HTML, even simple tasks would reload the browser with a new Web page after every mouse click-clearly limiting business productivity. For these reasons, the full adoption of Web application computing was severely derailed for a time. However, HTML forms did act as the impetus for the next evolutionary Web technology: Java applets and custom browser plug-ins.

Applets: Plugging into the Next Best Thing

Applets and Plug-ins are capable of delivering rich Web applications, but at high cost to the enterprise and the end-user. Java applets and other custom plug-ins were developed to enhance end-user interaction within a Web page--successfully overcoming most of the obstacles associated with HTML forms. Java applets allowed developers to deliver real client applications within the browser. The resulting Web applications were much more functional than HTML forms had been; however, serious issues quickly emerged with applet and plug-in delivery.

As newer versions of Java entered the market, they were not automatically incorporated into the browser, forcing users and/or administrators to assume the burden of client/server-like maintenance and upgrade issues. And although simple applets performed well, large and complex business applications built on applets were unresponsive, sluggish and did not meet user performance expectations.

Deeper technical issues have also plagued Java in the browser. These issues include paint and refresh problems (evident by screen flickers), lack of a rich widget set and inconsistent views across multiple operating environments like Linux, Mac and Windows (relying heavily on the operating system widgets).

Although technically functional, the broad use of Java applets, as a means of accessing Web Services, hasn't captured total market attention and has fallen out of favor with both developers and enterprise managers alike. However, Java applets did invigorate the tech industry's imagination on what was possible in a browser environment.

Another effort to deliver fast, graphic-intensive Web applications was lead by Macromedia's proprietary technologies--Flash and Shockwave. These were added to the browser as platform-specific plug-ins that, like Java, required new development skills and methodologies. Unlike Java, Flash and Shockwave have been extremely successful in enhancing the user experience but have not provided a true "Browser Application Platform." Flash enjoys great market acceptance as a multimedia environment; however, despite recent efforts, questions remain on whether enterprise developers will adopt the designer-focused development paradigm.