Abstract

In last month's column, we began our series on intranet application techniques by discussing the differences between the Web and the client/server model as platforms for delivering applications. This month, we'll look at the applications themselves. What sorts of application features have users come to expect? How do the Web and client/server platforms differ in their abilities to deliver these applications? We'll see that Web technology allows for the combination of rich content and transaction-based logic, making the application more informative and compelling for the user. Web technology also allows applications to be designed for every employee in the enterprise, not just the limited number of people for whom client/server applications have often been designed. If you missed last month's installment, see Part I now. (2,100 words)

To put the revolutionary nature of Web-based applications into perspective, let's consider a traditional client/server application that, because of its non-mission-critical nature, is an excellent candidate for conversion to intranet technology. Suppose you have built or purchased an application for managing your company's 401(k) benefit plan. Most likely, the application was designed for use by members of the HR department only. It might allow them to check and change employees' fund allocations and to perform various administrative tasks such as printing reports on fund allocations across the company. HR people would have the client side of the application installed on their desktop computers, which would communicate with a database on a network server.

Now let's say you want to make a change to your personal 401(k) fund allocation: You decide to move 20 percent of your payroll deduction from the sleepy, boring stock index fund to the exciting, aggressive Former Communist Nations Growth Fund (FCNG Fund), which was just added to the list of fund choices in your company's 401(k) plan. You would need to fill out and submit a paper form to the HR department. If you wanted information about your investment options, or you wanted a prospectus for the FCGNF, then you would have to ask for documentation on the information, probably in the form of a booklet produced by either the HR department or the fund company. Most large HR departments stock hundreds of these documents, which must, by law, be updated each quarter to reflect the most current information.

Once you have filled out the form, you would return it to HR, where someone would key the information into the client/server application, which in turn would update the database. The application might then print an update indicating that the change had been made, and the HR department would route the update back to you. In all, this is a tedious process that should be much simpler.

On the other hand, consider what might happen if this application were Web-based. You could use your Web browser to access it, without having to install any special client software. It would be easy to include information on fund choices and even hyperlinks to the home pages of fund companies. You might even get some feature that does "what-if" analysis for various fund allocation strategies based on those funds' past performance. You could then make changes to your fund allocations with an HTML form and have those changes reflected in the database immediately. You could also check your account balances, among various other things.

Of course, it's possible to develop a client/server application that has all of the above features. But would you want to build such an application if you had to develop multiple versions of it for every desktop system in your company? Or, if you could buy an application, would you really want to purchase that many clients? By building a Web application, you are able to develop it once and roll it out to everyone with very little effort -- just by sending everyone an e-mail with the URL. As icing on the cake, you've reduced the tedium level in your HR department, you have eliminated the need to stock (and constantly update) booklets of fund information, and you have given all employees direct control over their own investment decisions.

Intranet by design
Now let's look more closely at these two applications to better understand the differences between them. The client/server application is installed only on the desktops of the HR staff and is designed for use specifically by the HR department. In last month's column, we discussed the various complexities associated with client/server applications that make them hard to support. Such complexities induce many IT departments to limit distribution to as few desktops as possible. This decision has implications that go all the way back to the design of the application.

When any application is designed, the user interface is usually developed by gathering requirements from the end users. The completed application is an implementation of a solution to the problems thought by a particular group of people to be the most pressing for their needs and level of experience. The user community in the client/server version of our 401(k) application case is the HR department, and its requirements can be very biased towards its own views about how things ought to work. The experience level and particular tasks of the HR department are probably very different from employees in general, meaning that the user interface will end up being very specific for the HR's needs and probably quite inadequate for the larger employee community.

Yet the nature of Web technology allows us to design and deliver applications for every desktop in the enterprise. Such applications must be designed and built with the entire workforce in mind, from the most non-technical users up to and including the application developers themselves. While this wide range of experience may present a bit of a challenge in designing the user interface, the nature of the underlying technology makes the implementation of such an application quite trivial. Hyperlinks are especially useful for designing an application that provides complete functionality and user-friendliness to both novice and advanced users. To understand the reason for this, we need to look at the differences between the two platforms in their abilities to deliver different parts of the application.

The client/server platform is very good at delivering text-based, transaction driven data to the desktop. Because of this, most client/server applications are essentially forms based. The user typically sees screenfuls of input fields that are either hard-coded into the application or filled in dynamically with data retrieved from a database. The application usually relays textual data back to the user in some regulated format.

If multimedia content is to be included in a client/server application, then as we saw in last month's column, a fairly complex process is involved. First, the content creators -- the artists, camera people, sound people, editors, etc. -- must work together to create the files that are to be embedded into the application. When they are finished, the content creators turn the final product over to a software engineer who then weaves the media presentations into the executable code. Once the content is embedded into the executable, any change to the content requires a new build, and the generation and distribution of a new executable.

If the application must include dynamically updated multimedia components, the components must reside in a database or on the server's file system, and the format, content type, and structure of that data must be rigorously defined before implementation of the code that accesses the data.

In our 401(k) example, if the new FCNG Fund included multimedia prospectus information (e.g. with Java-based video clips, including one of new factory construction in Kazakhstan), it could require recoding and redistribution of the application -- which is itself a potentially complex task. The only reasonable way around this complexity would be to settle for digitizing pages of an informational booklet and having the application display the page images. As anyone who has experienced digitized versions of documents knows, this is far from the optimal solution -- and it takes up needless amounts of bandwidth on the LAN.

As we discussed last month, Web-based applications are composed of many different object types bound together with a standard method, the hyperlink. Use of hyperlinks allows a designer to quickly and easily redirect users to objects containing the very latest versions of information. This data can be of any type, and the type can change with each access, without any knowledge or collaboration of the object that references it. We called this flexibility "loose binding" in last month's column. In our example, the Web-based 401(k) application administrators could put up the new multimedia FCNG Fund prospectus easily, with no negative impact on the application at all.

Affairs of state
If the application requires connection with a database, as our 401(k) example would, a client/server application makes the connection over the LAN and maintains that connection as long as the transaction is in progress. Once complete, the application commits the transaction, and the database connection is terminated. The database management system (DBMS) assures the integrity of the data because the DBMS can roll back incomplete or erroneous transactions.

Thus, Web technology makes it much easier to incorporate multimedia elements into everyday corporate applications. And users of the (external) Web have come to expect such rich content as the worldwide race to attract Web-cruisers to Web sites rages on. But, of course, there are drawbacks to the new technology. For example, it's more difficult in the Web world to implement robust, atomic database transactions. The underlying HTTP protocol is a request/response scheme, wherein the browser requests a page or action, and the server responds. There is no sense of a permanent connection in HTTP, which, until recently, made working with a database cumbersome.

Database transactions require that a sense of state is maintained between the client and the server. A basic transaction, like a simple query or insert, is relatively easy to handle with HTTP, because the entire transaction can be completed in one request/response cycle. However, things become difficult when multiple queries are needed to complete a single transaction. At this point, it becomes necessary to construct some type of connection maintenance mechanism that can determine whether a particular request belongs with a previous request or to a particular user who has made a recent request.

Anyone who has tried to perform a complex transaction over an online service should understand the difficulties involved. For example, if you book airline tickes using the Easy SAABRE system on CompuServe or AOL, the service will guide you through a series of steps that include adding flights to your itinerary, choosing your seats, and paying for the tickets. CompuServe and AOL employ custom-built clients and protocols that allow state to be preserved on your end throughout the duration of the transaction, even if your phone line hangs up or something else breaks the chain of events. You could log back in, and because of information stored on your PC, the online service would remember where you left off, just like an internal client/server application.

Now consider trying to book tickets over the Web on a site like Travelocity, the new Web implementation of Easy SAABRE. If your line disconnects, then there is no information on your end that helps the server reestablish contact when you reconnect. The server must compensate for the lack of sophistication of the underlying HTTP protocol by constructing additional bookkeeping mechanisms on the server side. Luckily, this task is now much simpler, due to the release of HTTP APIs from the major server vendors, in conjunction with database connection schemes such as JavaSoft's Java Database Connectivity (JDBC). As these technologies mature, the ability to integrate the transactional processes of a client/server application with the abundant content of Web technology should become as straightforward as it was in the client/server environment. When this happens, another major obstacle of moving your corporate applications from client/server to intranet technology will go away.

By combining the Web's strength in delivering rich, dynamic content with robust transaction-processing capability from the traditional client/server world, future Web-based applications will be both compelling and thorough, while being able to support business critical transaction processing. This new breed of applications will be available to every member of the enterprise, changing the shape of not only the IS department, but of corporate applications overall.

A new platform capable of delivering this new type of application will require a revolutionary development environment. We will look at the requirements for such an environment 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:

• JavaSoft's Java Database Connectivity (JDBC) http://splash.javasoft.com/jdbc
• Travelocity http://www.travelocity.com
• "A revolutionary platform" the October 1996 Client/Server column in SunWorld Online http://www.sunworld.com/swol-10-1996/swol-10-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-11-1996/swol-11-cs.html
Last updated: 1 November 1996