The select.pl service shown in Listing 6 takes a single parameter—the id number
of the record to be retrieved. The result is an XML file containing all
the fields in the record and the appropriate values. This allows us
to call the function with a record id and retrieve all the fields of
that record for later manipulation.

Finally, the update.pl service shown in Listing 8 takes a record id, a field
name and a new value as parameters. Then, the program updates the given
field of the selected record with the new value. The new field value is
then returned via XML.

Granted, our little application is fairly trivial, but it does perform
all of the basic functions that need to be performed on a database:
insert, delete, update and search. More important, no single element
of this application is difficult to write, debug or understand. In
fact, with a few improvements that I outline next, the Web Service
scripts and much of the JavaScript can be reused for other parts of a
larger application or even many different applications. The Web Services
simply become bricks that are glued together with JavaScript to build
applications, and this is what makes using Web Services such an elegant
method of Web development.

From the user's perspective, using Ajax to perform the database functions
is a major win. As mentioned before, once the application is loaded,
users never have to incur the cost of re-downloading it and having their
browsers re-render it. On more complex pages, this can be a significant
delay. Furthermore, because the results of a given operation are returned
in small snippets of XML, the bandwidth requirements are minimal. It's
arguable that not only would users perceive this type of application
as faster, but it also would put lower demands on the server and network
infrastructure that provide the application.

But, how hard would it be to add a new field, perhaps an e-mail address,
to our application? Well, we'd have to add an appropriate field to our
database table scheme. Then, we'd have to add the field, with the same
name, to our HTML document. We could use the other form fields as a
template of course. And, that should just about do it.

So, how could we improve our code? First, we'd need to take
care of some glaring security issues. Our Web Services should use some
form of authentication to make sure that only authorized users can
perform database functions. More subtly though, the Web Services need to
perform some basic validation on the parameters they receive. The
delete.pl service accepts a record number in the form of id=25 as
a parameter. What if someone wanted to be mean and, instead, sent id=25
or 1=1 to our service? Well, our database would be gone because 1=1 is
always true, and our program would delete all
records. So, we would have
to take care of such issues before we could use these services in
the wild.

You may have noticed that all of the fields in our database are of type
varchar(20). That's not very flexible or efficient. To be truly useful,
our services would need to be able to query the database to determine what
data type a given field was and act appropriately. For example, chars
and varchars need to be quoted, but integers and booleans do not. The
service should be able to determine how to handle these situations.

Finally, by simply sending the name of the table as one of the parameters,
we can build a Web Service that can modify database tables other than
our contacts table. We'd be able to use the same services to update
a shopping list, inventory or calendar. Generalizing our Web Services
like this would make our simple contacts application easy to write as
well as any other application in which we chose to use them.

So, by coupling Ajax with our own brand of Web Services, we're able to
write applications that are more responsive to user input, less taxing
on the server infrastructure, and much easier to write and maintain.

Mike Diehl is a contractor at Sandia National Laboratories in
Albuquerque,
New Mexico, where he writes network management software. Mike lives
with his wife and two small boys and can be reached via e-mail at
mdiehl@diehlnet.com.