"Doing right" in application-server terms means getting the stuff an application needs from various sources and delivering stuff from the application. When talking about data sources, getting and delivering corresponds to reading and writing data.

In general terms, application servers get and deliver stuff to three broad classes of systems: relational databases, from which it gets SQL results sets; legacy and packaged applications, such as SAP, Baan and PeopleSoft; and data emerging from distributed objects on the network, such as CORBA objects.

Over the next several columns we'll look at how application servers handle each of these sources. In this column we'll begin by looking at the first source, relational databases. This is probably the most common source of data accessed by application servers.

At first, getting SQL result sets from an application server seems pretty straightforward. Pass your request through the JDBC driver that comes with the application server and presto! You have your SQL results. In practice, however, it's not so simple.

For starters, many application servers, whether purchased or built by hand, are hardwired to proprietary database drivers for popular databases, which can hobble the application server. While a proprietary driver may be acceptable in the conventional client/server environment, it presents significant problems in the rapidly evolving Java world. Unlike the ODBC driver, which is middleware, the JDBC driver passes Java calls directly to the database. Database vendors and other parties continually bring out improved JDBC drivers for each database.

As a result, developers want to retain the flexibility to substitute the best JDBC driver for a given database. If the application server is hardwired to a particular database driver, no matter how good it was when first built (and it's quite possible that it wasn't very good even then) you can be sure it won't be the best now. And it will really be an impediment compared to whatever is out there six months or a year from now.

What's the best JBDC driver? It depends. Some will deliver better performance; others will consume fewer system resources. Some will come from big-name vendors offering tons of support; others will come from hot little startups that can't even provide useful documentation. Java developers like having these choices.

But there's more to the SQL result-sets challenge than the JDBC driver. The application server must also do an effective job of providing a cache of result sets coming back from the SQL call. This isn't trivial, as anyone who has tried building such a cache can attest. The cache must be controllable by the development team and should provide for threads that fill the cache, if necessary. It's also important to provide governors that limit the total number of rows captured to prevent swamping the application server with an unexpectedly large result set.

Finally, the application server must allow for data binding of SQL data to client controls. While this sounds obvious, it's a sensitive issue that can adversely affect quality, performance and maintainability. The Java client must have easy access to the data. And, once again, an elegant and effective cache on the client side is key.

The bottom line: getting SQL result sets isn't as simple as firing up any old JDBC driver that comes with the application server. In fact, you must think beyond JDBC and consider cache and client control.

Now that we've taken care of relational data sources and SQL result sets, we can turn our attention, in a subsequent column, to legacy applications. Here we'll explore the problems that arise when the legacy data doesn't necessarily map well into JDBC type structures. Stay tuned.