Abstract

In the past two articles, we discussed the differences between client/server and Web environments in terms of development platforms and the types of applications the two can support. The Web is a component-based environment where the individual components are loosely bound with hyperlinks, while client/server applications are typically more homogeneous and tightly bound through such mechanisms as detailed object method definitions.

Web applications can combine rich content with transaction processing, and they can be delivered to every desktop in the enterprise. These differences lead to equally important differences in the kind of development environment that is required for creating Web applications. In this month's column, the final installment of our series on the Web application development paradigm, we will focus on the requirements for such an environment. Coauthored with Pat Greer (2,300 words)

If you have done development in the client/server world and you are now moving to the Web world, you should understand why development environments designed for client/server aren't ideal for Web applications. With the abundance of component types present in Web development, it is actually more accurate to think of the necessary environment as an assembly environment rather than a development environment. Instead of a tightly integrated environment, as was found with client/server tools like Sybase's PowerBuilder and Borland's Delphi, the Web environment can be thought of as an assembly tool that developers can use to create a functional application out of many different types of component objects. Here are some of the fundamental requirements for a Web assembly environment:

• Support the total application
• Support the full life cycle
• Interact with all authoring tools
• Support all component types
• Integrate with source control systems
• Understand relationships between components
• Accommodate new types of development teams

Let's look at each of these in some detail.

Support the total application
In the client/server world, development tools such as PowerBuilder are truly integrated development environments. A tool like this contains just about everything a developer needs to construct a complete application -- a screen painter for designing the user interface, a form builder for constructing database transactions, a scripting language (usually proprietary) for developing logic, a compiler, and a debugger.

In the Web environment, with the disparity of component types, there is no single tool that can create every object type and do it well. Instead, developers have learned to use a set of tools, each one specialized to create a particular component type. This proliferation of tools will likely continue, and even expand, as new component types emerge.

As the number of tools required to create a complete application increases, you lose the ability to maintain a sense of the overall application. Since none of the individual authoring tools interact with each other, the only way for you to keep track of the relationships between components is either in your own memory, or by building a directory scheme on the file system that provides clues to relations between components.

The new environment needs to restore the sense of the overall application so that everyone on the development team can get a visual sense of the interdependencies among components. There are products on the market now, such as NetCarta's WebMapper and The ForeFront Group's WebWhacker, that provide visual mapping of an application. They can't do so, however, until the application has been physically deployed to an HTTP server. The Web assembly environment should alert the developer that a problem exists, such as a broken link or missing file, before they put the object out where people can see it. Along the same lines, when a new component is added to the environment, the environment should recognize any references to other components that are not yet a part of the environment and alert the user that those components should be included for completeness.

Support the full development life cycle
To provide the maximum value, an assembly environment must support the entire life cycle of the development process encompassing original design, development, test, deployment, ongoing maintenance, and enhancement. A tool that doesn't look at components until they are already being served by an HTTP server has missed a major portion of the process. Instead, you should be able to start with nothing more than a design and create, test, modify, deploy, and maintain every component of the application.

You should be able to define multiple deployment stages for your application. Your team can deploy to or work in separate development, test, and production environments, each with its own directory architecture, each independent from the other, with the development environment tracking the state of every one. The environment should understand the state of each stage, so that you can quickly and easily see what components have been deployed, what has changed since the last time a deployment occurred, and other similar information. In addition, the environment should be able to locate components that have become unlinked (orphaned) through changes to the referencing page and notify you of such orphans.

It's especially important to track changes to applications. One of the major differences between client/server applications and Web-based ones is the constant change that Web-based applications experience. A Web application is never "finished," so to be useful, the environment that manages the application must allow the developer to maintain different portions of the application in different states of development at the same time. One particular function, such as user registration, may be fully functional and in use by the user community while another function is still in the design phase. A Web-based environment must be able to maintain the integrity of the entire application, while providing the developer with the ability to create, modify, and maintain each component individually.

Interact with all authoring tools
Tools for creating Web components are in their infancy. Just compare the tools available six months ago with the newer tools to see that vendors are still sorting out what features provide true value and which ones do not. Of course, tools will get better and better as the authoring market matures, and it's equally axiomatic that developers will want to use the "latest and greatest" at all times to create individual components.

The challenge for a Web development environment will be to integrate with these tools. The development environment must understand which tools you are using to create each type of component, invoke them when required, and serve as the point where the tools' outputs are assembled into a complete application. An environment that restricts choices of tools is a dead end.

Even more important to the long-term viability of a Web development environment will be its ability to support new tools as they emerge.

Support all component types
A Web-based assembly environment cannot be limited in the number of component types it can understand and support. Most development is currently being done with four types of components: HTML (either static or dynamically generated), images, database connectivity components, and -- increasingly -- Java applets. In the not too distant future, streaming audio and video, VRML, and other component types will become more common, and the tools to author those components will require support within the development environment. Most development environments for the Web understand a fixed, "hard-wired" set of component types, and they can offer no support for the types they do not understand.

Vendors who make tools with such fixed frameworks will never be able to release new versions of their tools as fast as new component types emerge. Instead, the environment should have an open framework for integrating whatever types of components emerge. As explained in SunWorld Online's September 1996 Client/Server column, such a framework ideally is expressed as an object-oriented type model, where Web application component types are modeled as object types with methods and properties. Users of such environments should be allowed to register new tools and component types by defining their properties. The environment would then track the new type's properties as the user created and maintained the components.

For example, a new group of tools is emerging that support the creation of database transactions in Web applications. We've seen examples of such tools in this space in previous months, such as those from NetDynamics (formerly known as Spider Technologies) and Bluestone.

Each of these tools has some component types that are created and become necessary for the proper functionality of the application, such as NetDynamics' .DLL and .EXE files and Bluestone's CGI engine. But the components are proprietary to the tool and will not become standards in the Internet community as a whole. Because these tools add non-standard items to the runtime environment of a Web application, using them limits your ability to change the tools and component set you use. A comprehensive Web-based assembly environment should let you incorporate these new component types so that the environment manages their existence just as it does for HTML files.

Integrate with source control systems
As we implied above, one of the most demanding tasks in developing and maintaining a Web application is managing change control. Change control becomes more and more intractable as the development team expands and the number of components grows. Working on the wrong revision of a particular component, overwriting other team members' work, and replacing a particular component in the production environment with an older version all become more common as the complexity of the application grows. A good environment should provide file check-in and check-out, strict revision control, and file-locking mechanisms. Since most IT departments have a revision control system installed, and therefore have already made a fairly significant investment in software and training, the environment should integrate with the existing system rather than (or in addition to) providing its own.

Understand relationships between components
The goal of any assembly environment should be to simplify and automate the job of the developer as much as possible. Currently, Web application developers spend a major part of their development time making sure hyperlinks are maintained as they create and modify components. For instance, if you are designing a 401(k) application like the one we discussed last month, you might create separate directories to hold the information for each of the available funds. Now suppose that your company grows to the point that there are not only several different funds, but even several funds from certain categories -- you might have three or four funds specializing in emerging markets, a few bond funds, some index funds, etc. The number of options grows to a point at which you decide to rearrange the directory structures in your application to handle the complexity.

As anyone who has lived through this process knows, it is tedious and time-consuming. You must check every link in the application to ensure that you haven't compromised the integrity of the application. What usually happens is that you either go through and manually change each link, or you might write a shell script to accomplish the task. In either case, you have to check the entire application for integrity.

A decent Web development environment should handle this task automatically. It should keep track of the relationships between components in a way that is independent of the directory structure of the server where they will reside, and it should do so with little or no intervention from the user. This frees you to concentrate on the task at hand -- building a robust application.

Accommodate new types of development teams
As we discussed in the previous columns in this series, the development team for a Web-based application is broader and more diverse than that of a client/server project. The new environment must be flexible enough to accommodate both traditional programmers and creative professionals such as graphic artists, writers, and editors. The key to a successful environment will be its ability to provide a common method for all individuals on the team to visualize the application as it is developed. Each member of the team will be concerned with his or her own components, yet everyone needs to be able to visualize the interdependencies between components so that they are aware of the impacts of any changes they may wish to make.

In addition, the environment should provide some notification to developers when components have changed. Ideally the environment would even make the necessary adjustments for changes when possible. For instance, if one were to decide to change the name of a particular component, the environment should find all the references to the old component name and modify them to reference the new name.

Moving forward
It took almost ten years for development environments to evolve in the client/server arena, and even then they were built, for the most part, on proprietary scripting languages. The Web environment is fundamentally different from client/server in that it is component-based, much more dynamic, and involves a different set of people who develop applications. A new set of tools will emerge over the next year or two that will remove the tedium currently associated with developing Web-based applications. We can expect a significant gain in productivity, ease of use, and overall functionality as these tools mature.

If you are looking for this type of tool, you should search out the ones that are architected for an open environment and embrace all the standards currently in use on the Web. These standards must be flexible enough to adapt to new standards (and fads) as they appear. This way, you can ensure that an investment in this area will pay off over time as the Web application landscape changes.

Resources

• Sybase's PowerBuilder http://www.powersoft.com/products/index.html
• Borland's Delphi http://www.borland.com/delphi/
• NetCarta http://www.netcarta.com/
• The ForeFront Group's WebWhacker http://www.ffg.com/whacker.html
• NetDynamics (formerly known as Spider Technologies) http://www.netdynamics.com/
• Bluestone http://www.bluestone.com
• More on application development in SunWorld Online's Site Index. http://www.sunworld.com/common/swol-siteindex.html#appdev
• Earlier Client/Server columns http://www.sunworld.com/common/swol-backissues-columns.html#cs

Bill Rosenblatt is an Enterprise IT Architect at Sun Microsystems, where he specializes in media technology. Reach him at bill.rosenblatt@sunworld.com.

Pat Greer is vice president of professional services at Wallop Software. Reach him at pat.greer@sunworld.com.

Bill Rosenblatt is the author of Learning the Korn Shell and a coauthor of Learning Gnu Emacs and Learning the Bash Shell. You can buy these at Amazon.com Books. Select the hyperlinks to learn more about each and Amazon.com.

If you have problems with this magazine, contact Webmaster@sunworld.com
URL: http://www.sunworld.com/swol-12-1996/swol-12-cs.html
Last updated: 1 December 1996