Active clients: Flexibility and Performance
At first, a publishing model formed the basis for the Web which
was then expanded into an interactive model. But, the model limited interactivity,
security, retention of state and client integration. Active clients address these problems
by defining permanent software systems. A number of implementation approaches are
available.
The Internet continues continues to search for an identity. At first, the Net consisted
of e-mail, file transport and remote login in a character-based environment. Then came the
Web with the potentially unlimited power of a hypermedia model using a markup language.
This permitted the integration of all media: audio, video, graphics and executable code.
Consequently, it attracted a wider spectrum of users.
This environment unlocked the Net, permitting a more attractive and usable interface.
But, the Net had limits. It was necessary to operate in an environment where the size of
the available screen could vary. This required a block-oriented markup environment,
thereby limiting the layout of information.
At first, a publishing model formed the basis for the Web. Interactivity was limited,
since the model was essentially one-way. The Web, consisting of pages comprising a site,
was expected to be read by the user. After reading a page, the user would move on to the
next. When user input entered the picture, rather than defining a new model, the
publishing model was pushed to its limits.
Interaction with the Web usually occurs through a special interface: the browser, which
results in an operating system independent, rendering of the information. While machine
independence is a desirable goal, it has drawbacks. The greatest is the row/column
paradigm that must be followed in laying out the information. When the Web was used for
displaying information, it was a mildly inhibiting environment. Now, when input is
required, it limits many of the interface techniques based upon direct object
manipulation.
Using a simple client / server architecture, the Web operates as if the client computer
has the power of a mid to late 1970s smart terminal. But, today’s personal computer
has the equivalent power of many mainframes to which the smart terminal was attached.
Security has always been a serious problem on the Net. Because of this, the browser has
operated in a "sealed" environment. As long as the application does not access
information outside the control of the browser, the client computing system should remain
safe.
This security comes at a considerable cost. With the exception of cookies (small text
files) and a history of pages viewed, the Web is unable to maintain information from one
session to another. Each Web page has no connection with another. For a display
environment, the initial domain of the Web, this is not a hindrance. But, in a commercial
environment, this severely limits the Net's capability.
In summary, we are operating in a state-free environment, where the mode of interaction
takes up back to a more primitive system than that existing in the 1970's, albeit with a
more sophisticated looking interface. The comprehensive ability to have session to session
continuity does not exist. To overcome these deficiencies, considerable server-side
processing is required. The result is the collapse of the system as occurred during the
holiday season on many commercial sites in 1999.
A Solution: Active
Clients
What would occur if we introduced a client / server system circa 1990 rather than the
terminal-based system of the 1970's? The most noticeable difference would be in the
client. Rather than operating as an application running within a closed environment, it
would be a program operating in native mode on the client. This program would be able to
take advantage of the entire computing platform: both hardware and software. This is the
model for an Active Client.
The active client model assumes that a permanent application is installed on the
client. It differs from a temporarily Java applet. Because of its permanent, it can be
configured to the client. Not only will this include options that controls the application
between sessions, but provides access to data that integrates the Internet into a more
traditional application paradigm.
This model deviates from the general Web architecture where everything is temporary.
The permanence provides the basis for reintroducing state or program status back into the
computing environment. This permanence is required for the next-generation Web
applications.
For this to occur, a dramatic shift in the Internet perception must take place.
Searching for models is easy; one only needs to look back to the use on local area
networks (LANs). Initially, the user was aware of the existence of the LAN; logging onto
the server was an activity that was a necessary precursor to using the information or an
application. Later, the LAN shifted into the background; now the LAN was an extension to
the local computer.
The emergence of full-time connectivity, either through a LAN, DSL or cable will
integrate the local computer with the greater body of the Internet. No special action will
be required to have Internet access. Then, the natural evolution of local software will be
the inclusion of Internet connectivity into many applications. These applications will be
active clients
Active clients are not intended as the sole interaction methodology of sites on the
Internet. These clients are highly applicable to sites or groups of sites with which the
user interacts on a more or less continuous basis. The overhead of installing an active
client is not warranted for the casual user. Yet, an active client, with its inter-session
capabilities, its ability to embed high security and improved user interfaces will make it
an attractive option in the future.
Active clients exist today in sites containing streaming media, such as Real Audio. In
this case, they are used to view and hear content. They are either designed ad plug-ins of
as separate applications. Later, the active client will focus upon business to business
and financial sites where the inter-session capability and the ability to integrate with
other software will make it the client of choice.
The active client model can be implemented in a number of ways. First, it can use a
conventional programming language. This places the Internet in the position of extending
the computing environment of the client platform. While this may limit portability, it
places all the tools and their associated power in the hands of the developer.
There are alternative approaches. Middleware can act as a buffer between a Java applet
and the computer-operating environment. It allows data to be stored and retrieved without
allowing the code to directly access a native file. This approach operates as an extension
to cookies by creating a virtual file system. The applet queries the middleware, which
then performs the access to the native file system. It acts as a firewall between the
potentially dangerous, down loaded code and the file system. While this alternative
permits the storage of inter-session information, it does not improve the quality of the
user interface. Products such as Inprise's VisiBroker for Java can be used today if the
CORBA Object Request Broker is used.
Lastly, a new delivery environment, designed to operate with an expanded version of
Java or another interpreted language, will emerge. It will permit a richer I/O
environment, together with an integrated object-based database to address inter-session
storage. It is likely that this will emerge as an extension of current browsers and Java
together with the middleware discussed above.
The use of active clients addresses many of the issues raised above. They will change
the basic publishing model of the current Web to a computing model. Because of the
improved, secure connectivity with file systems, usable inter-session information can
emerge. This can, of course, lead to abuse as was shown in 1999, where the Real Audio
Jukebox stored user selections.
The use of conventional development languages, such as C++, leads to better user
interfaces. With the reduced cost of processing and storage, together with increased
performance and storage capacity, the active client on small appliance-sized devices will
grow.
While this model is advantageous, its adoption will take a minimum of three to five
years. They will require advances in client technology together with the adoption of a
more active role for the client. As the capabilities emerge, we expect that this approach
will rapidly gain acceptance due to its increased flexibility. It will allow developers to
provide better sites to their users.
Action Items
Software vendors – The development of active clients will require new tools as
indicated above. Not only will middleware products emerge, but there will be a need for
tools to send and receive messages sent from the server to the client. Those involved in
developing HTTP standards should consider a tag that can send appropriate information to a
client without triggering a page event.
Application developers – Examine your applications to determine how an active
client fits into your strategy. We expect that business to business vendors will identify
opportunities where the operating environment of the clients is well known and an active
client provides a more usable interface.
Entire contents (C) 1999 by Integrated Business Information Systems Ltd..
(IBIS, www.ibisl.com) All rights reserved. Reproduction of this publication in any form
without prior written permission is forbidden. The information contained herein has been
obtained from sources believed to be reliable. IBIS disclaims all warranties as to the
accuracy, completeness or adequacy of such information. IBIS shall have no liability for
errors, omissions or inadequacies in the information contained herein or for
interpretations thereof. The reader assumes sole responsibility for the selection of these
materials to achieve its intended results. The opinions expressed herein are subject to
change without notice. |