Abstract

In this and the next two Client/Server columns, I am joined by my long-time friend and colleague Pat Greer. Pat is currently Vice President of Professional Services at Wallop Software, whose Build-IT (formerly Wallop WorkShop) development environment I discussed in last month's column. In this series, Pat and I will look at the emerging discipline of intranet application development, examining how it differs from traditional client/server development and the tools and procedures are required to do it right. In this first installment, we'll focus on the differences between the two paradigms. (2,300 words)

Web technology offers companies the ability to deliver applications to each desktop in their enterprise more easily than ever before. Installation and porting to multiple platforms, typically resource-eating booby traps, are trivial or unnecessary. As more companies adopt this attractive approach, more complex corporate intranet applications are being developed. If you're a developer of business applications, you should understand that intranet technology is fundamentally different from traditional client/server technology, and therefore the development process needs to change.

Client/server versus WWW as Application Platforms
There are three basic differences between applications developed in a client/server environment and those developed in the Web environment. The most important is what we'll call tight binding versus loose binding. Client/server applications are tightly bound; they consist, for the most part, of compiled code that is linked together to form executables. Web applications, by contrast, are collections of files strung together by URLs. The code base of a client/server application runs though a compiler that binds the code according to precise routine-calling conventions. An application may contain dynamic links, but those are also made up of compiled executables. When a particular piece of code is missing, out of date, or otherwise out of sync with the rest of the application, the house of cards collapses.

Intranet applications, on the other hand, have individual components of a Web application, are never compiled into a single executable; hence, they are loosely bound. If a particular object is missing or out of sync, the user is not aware of it until invoking that portion of the application. This means that files can be missing, wrong versions can be available to the user community, and so on, but no one may notice the mess until trying to access the spurious object.

The development team in a client/server environment conducts system builds that include the contributions of all of the members of the team into a single compile. If a particular piece of the code base has not been developed sufficiently to include in the build, then the team must take special steps (such as writing a stub) so that the compiled application will run. Often, testing must carefully avoid the missing functionality to keep from crashing the application. No such extra effort is necessary in intranet development situations. Because each object (or group of objects) can operate independently of the others, the only step necessary to test a particular piece of functionality is to deploy the required objects to the Web server. If a particular piece of functionality or content is missing, the only impact in most cases is that a server error message will appear on the browser.

The second important difference between client/server and Web applications is in the programming or authoring tools used to create application components. Client/server application code is usually developed with a single authoring tool. Nowadays, this means a GUI-style application builder like Powersoft's PowerBuilder or Borland's Delphi, or it could mean a tool built around a 3GL like C or C++, such as Microsoft Visual C++. These tools contain such amenities as a screen painter, forms generator, code editor, compiler, and debugger. Even if you are simply using a 3GL without the fancy environment, the odds are that you are also using a number of other tools to make your life easier, but these tools constitute a fixed set. In either case, you will have to pick a single tool(set) and stick with it throughout the entire life cycle of the application.

A Web environment, on the other hand, has to include many different authoring tools. There are individual tools for creating HTML, images, script, audio, etc. Developers may use two or three different tools to create their parts of the application. The tools are independent, in that none of them understands the creation process of the others, and only in the case of a few HTML editors do they even know about the existence of the other object types. Most HTML editors only understand the existence of images.

Because of the loose binding among components of Web apps, individual members of the development team can select the authoring tool they prefer for the individual tasks they will be responsible for. Even if two developers are working on similar parts of the application, like the connection to a database, they can select different tools to develop their individual pieces, and the resulting objects will be able to function together in the Web environment. One developer may use Perl code, written in the Emacs editor, to perform the update of some particular data in the database, while another developer may use a server-side Java application that builds a query and returns the results. The two solutions will work together seamlessly, and final users will not know or care which tools or methods were used.

The difference in the number of authoring tools leads us to the third major difference between the environments: Web environments typically incorporate many more types of objects than client/server environments. Client/server applications consist of a small number of object types. On the client side, there is usually only one object: the executable file. Add server code and dynamically linked objects, and the number of types is still small. Web applications, on the other hand, are true component applications. They are collections of documents, executables, images, and several other possible file types.

The development team
Development teams for building client/server applications consist mainly of software engineers. Depending on the size of the project, there may be other individuals involved (analysts, database administrators, quality assurance specialists, etc.), but these people are still very technical. Even the project manager is usually a senior level engineer, or someone with a significant technical background. In general, all the members of the team use the same tools. These tools are generally chosen beforehand and used consistently from the start of the project to completion. (Rarely, for example, would a project team begin using PowerBuilder and switch to Delphi in midstream!) Everyone on the project must have a minimum level of expertise using the authoring environment, and everyone should be using the same terminology when discussing issues relevant to the project.

If a client/server application includes content, such as significant text, images, and sound, then a completely separate group of creative people is usually called upon to create the content. This group typically hands their finished product over to engineering for integration into the application; they rarely deploy their objects directly into the application.

A Web development team, on the other hand, includes both engineers and content professionals, all of whom deploy the results of their efforts directly to the application platform. As mentioned in the December 1995 Client/Server column, The disappearing line, the Web is causing the distinction between "applications" and "content" to blur. This implies that Web development teams must learn to accommodate two different development styles -- terminologies, work processes, etc. -- within projects. Project management has the task of integrating these elements of development style; as we said before, integration of development tools is less crucial because of the loose binding of Web applications. Let's look at these different development styles and see how they can converge.

Development methodology
Client/server development methodology is a direct outgrowth of traditional software development methodology. Although much research has been done on alternatives, the vast majority of client/server development follows a time-honored pattern. First, a core team of designers or senior engineers spend some time gathering requirements. They analyze the requirements and design a solution, and then the development team starts implementing the solution. The team may schedule an early demonstration or prototype of the application, but overall, the user doesn't get a chance to view the application and provide feedback until development is complete to a certain stage. Changes requested by the user community are analyzed and scheduled into a future release of the application.

The development methodology for a Web-based application is more complex. The two environments share the analysis and design steps, but the task becomes more difficult later in the process. The project manager must track not only the development of the functional code, but the development and delivery of the content. Content development follows a much different workflow than software development: it is a more iterative process, with more review and revisions.

Client/server development processes generally try to restrict the amount of change occuring between design finalization and application delivery. Because of the content-rich nature of Web-based applications, however, change is inevitable. The Web development process must not resist this change but use it to help deliver a better end product. It's easier to create a demonstration of the look and feel of an application, add functionality in a modular way, and implement changes in a specific area without affecting other areas. This means that the development team can get user feedback throughout the project and incorporate that feedback into the application quickly with minimized impact to the final schedule.

Some client/server methodologies have moved from the traditional "waterfall" model, where each step in the process is taken sequentially, to a "circular" or "spiral" model, where there is constant feedback from design, development, and delivery. The Web environment carries that model even further: the feedback loops can exist in parallel, so that users can give feedback to developers on one piece of functionality, while other developers incorporate feedback into another piece, and a third group of developers does initial work on a third piece of the application. When properly managed, this model becomes very powerful in delivering useful applications very quickly.

Application distribution
One of the most dramatic differences between client/server and Web platforms is in application distribution. In the client/server environment, distribution of the completed application is problematic. A corporate IS department must develop a roll-out schedule; users must endure work interruptions during installation; their desktop environments may have to be modified; database connectivity software may be required; and so on. IS can deploy a significant portion of its resources simply to ensure that a majority of users get the application installed within a given time. If a serious problem is discovered, or new functionality is to be added, the development team must build a new version of the application and go through the distribution process once again. This wasteful process may be repeated many times over in the life of an application.

Simplicity of distribution is one of the most compelling reasons driving corporations towards Web-based applications. Rather than having to maintain many applications on every desktop, the IS department need only configure a browser -- and more often than not, every new machine purchased comes with a browser already installed. Installation of the application on an HTTP server is a fairly trivial task: in many cases, the pre-release test environment is the same machine and HTTP server that users access when the application is made public. Distribution to users is completely trivial: IS need only issue an e-mail message announcing the URL of the new application. When modifications are required, they can be available immediately. The user is assured of using the latest version.

Life cycle maintenance
Distribution of Web applications is far easier than that of client/server applications, but the opposite is true for the job that a development team has to do to maintain an application. Maintenance of client/server apps is fairly straightforward, assuming that the development team is using a configuration management system and even the most rudimentary testing procedures. Most client/server authoring environments either contain or integrate with source-code control systems that can track changes made to the code baseline. Because the application must be compiled prior to being distributed, many problems can be found long before the user sees the new version. Development tools from make to today's self-contained GUI behemoths contain dependency-tracking functionality that forces the right application components to be recompiled; this ensures that the resulting application always contains the latest code.

Maintenance is nowhere near as straightforward in Web-based applications -- once again, because of the Web's loose binding. Since each object is an individual file on the server file system, and the files that make up applications are not bound together, maintaining the applications requires a significant effort. It's a full-time job to keep versions of files in sync, check for broken hyperlinks, and ensure correct functionality on every page. Compounding this problem is users' expectations of dynamic, constantly fresh content on Web pages; Web applications are never finished in the sense that client/servers applications are.

Don't touch that dial!
Loose inter-component binding, easy deployment, difficult maintenance, and wide-open potential for multimedia content -- these differences between client/server and Web applications imply that there is as great a gulf between Web and client/server as there has been between client/server and host/terminal applications; in development methodologies as well as in the applications themselves. There's a similar gulf between client/server and Web applications in terms of the kinds of applications that the platforms can support -- and in the apps that users are coming to expect. We'll explore these differences in detail next month.

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.

What did you think of this article?
-Excellent! -Okay -Poor -Too long -Just right -Too short
Comments:

• Wallop Software http://www.wallop.com/
• Build-IT http://www.wallop.com/products/default.htm
• "Easing large Web site woes with a Wallop" the September 1996 Client/Server column in SunWorld Online. http://www.sunworld.com/swol-09-1996/swol-09-cs.html
• Powersoft PowerBuilder http://www.powersoft.com/products/devtools/pb50/index.html
• Borland Delphi http://www.borland.com/delphi/
• "The disappearing line" the December 1995 Client/Server column in SunWorld Online. http://www.sunworld.com/swol-12-1995/swol-12-cs.html
• A list of other Client/Server columns in SunWorld Online.

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