RAD becomes routine -- almost

The return to a central computing model driven by the Web has made it both easier and more difficult to deploy applications. It's simpler because there's no code to ship out to every client; it's more difficult because there's no code to ship out to every client.

The road to rapid application development, or RAD, via the Web hasn't been very smooth. Borland Software Corp.'s IntraBuilder, an early Web app builder, based on the company's dBase database tool, didn't make much of a splash. Scores of other tools have promised rapid Web development and have failed--or at least have failed to get much of anyone's attention.

Fortunately, Web application development has become steadily easier because of maturing development tools. And the latest generation of RAD tools has made building working Web applications--with database connections, data validation and even some client-side functionality courtesy of Web browser scripting--a lot less arduous.

That is due at least in part to the same trend that first made Windows development tools such as Microsoft Visual Basic attractive and viable: the growing availability of standard components for constructing applications. It also helps that the scripting and presentation features of the latest browsers make Web applications a bit more like traditional client applications, and that scripting languages for both browsers and servers have become more standardized and more powerful.

Web development was once easily partitioned between programming and design; developers crafted the code that did the heavy lifting, while Web designers focused on building flashy front ends to exploit the code.

This began to change with tools such as Allaire Corp.'s (now Macromedia Inc.'s) ColdFusion. Prepackaged functions were hidden behind special HTML tags. The dividing lines between the developer and designer roles began to blur. The tag approach became an integrated part of Microsoft's Active Server Pages and Sun Microsystem Inc.'s Java ServerPages.

At the same time, a number of other server-side technologies based on the Web's standard Common Gateway Interface (CGI) have made it easier to build dynamic Web pages for deployment across multiple types of Web servers. Among the most commonly used CGI technologies are PHP and Perl.

The lines between design and development blurred even further as Web design tools gained more development capability, and as conventional RAD tools expanded their reach to target Web clients.

Macromedia's Dreamweaver UltraDev and Adobe Systems Inc.'s GoLive are examples of Web authoring tools that have moved toward becoming Web RAD tools. Their latest versions nearly complete that journey. From the RAD tool side, Microsoft's Visual Basic has entered the territory after the company's previous effort at Web RAD, Visual InterDev. Borland's Delphi has also become a Web application tool.

Relatively solid standards for client scripting and page display have made these tools possible, though "relatively" is still the operative word. There are still plenty of differences between the leading browsers, so using a RAD tool to generate a solution for every possible user is no simple task.

On the client side, support has become more consistent for JavaScript. Although Microsoft's JScript--a clone of JavaScript--has been submitted to the European standards body ECMA as a standard called ECMAScript, almost all Web browsers support JavaScript. But there are still enough differences to require thorough testing on multiple types of Web browsers before you deploy an application, if you can't rely on a standard browser.

With powerful and comparable features available from both Java and Microsoft servers, and an increasingly good common denominator among all Web servers, many of the difficulties have diminished in building and deploying applications for multiple target servers from early RAD tools for the Web.

But there are still hurdles to be overcome on the client side, and the Shangri-la of a single application version that can be run by all users is a long way off.

Another feature of current browsers that has made Web applications more like traditional fat-client programs is dynamic HTML (DHTML), which lets Web pages change without having to be refreshed by the server.

This technology reduces round-tripping--the passing of data back and forth between client and server--and can significantly improve the performance of Web applications. But implementations of DHTML aren't consistent across browsers, so applications written using DHTML might not work on all browsers; and if some users are trapped with older versions of browsers because of their hardware or operating systems, they may not be able to use the apps at all.

One way to deal with this problem is with cascading style sheets, an approach to Web design that offers multiple nested ways to present a page, based on the capabilities of the browser. Although not all browsers can use the best version of a Web application, they might at least be able to take advantage of its core functionality.

Now, Web components are being taken to a new level. The power of enterprise applications is being directly exposed to Web applications through a new class of application integration technology known as Web Services.

Web Services, based on emerging standards such as the Simple Object Access Protocol (SOAP) and XML-RPC (Extended Markup Language for Remote Procedure Calls), makes it possible for developers to wrap existing applications as Web components.

Other software programs can leverage their functions by passing instructions to them using the same Hypertext Transfer Protocol that passes Web pages over the Internet. That makes it possible for applications to be accessed by other software running within an enterprise network or on the other side of the firewall. Requests and responses are formatted in Extensible Markup Language.

The Web Services model is still gaining traction with developers, but it promises to put the power of legacy systems and enterprise software within relatively easy reach of RAD tools and Web developers. It also is redefining Web applications, because Web services can be built to connect two pieces of software directly without a Web browser (or any graphical interface) ever coming into play.

Look, Ma, no wire


Another technology changing how Web applications are built is the wireless Web. Although technologies such as the Wireless Application Protocol have been slow to catch on--mostly because of slow performance and the difficulty of data entry on a cell phone--handheld devices are increasingly being used to access corporate data. Some RAD tools offer a way to target applications for them.

The Wireless Markup Language, a specialized version of XML based on HTML, can interact with a Web server application. FormWeb Software's FormWeb platform is one example; it creates application forms that can be rendered in WML, HTML or even VoiceXML for voice-response phone applications.

Many tools that often claim to be RAD tools are in fact really just integrated development environments, more suited to code-intensive development than rapidly plugging together components. But, depending on your needs, you'll probably want to get down into the applications generated by RAD tools at the code level, both to see how the code works and to customize it to meet your agency's Web standards.

Kevin Jonah, a Maryland network manager, writes about computer technology.

Related Articles

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above