Whether you need these techniques depends on program requirements and
whether you need to make an application highly interoperable. If you need
interoperability, you use ODBC functions and JDBC metadata classes to determine
at runtime what features, SQL dialects, and data types the DBMS or database
driver support. Adaptive programming techniques exploit these capabilities to
craft code that can operate against various SQL back ends.
Features, SQL dialects, and data types often change as DBMS vendors roll
out new versions. Adaptive techniques let your program work with a different
DBMS without having to rewrite or recompile it. They also add flexibility to
programs that work with only one type of SQL DBMS. Adaptive programs interrogate
the driver about supported features. The JDBC DatabaseMetaData class and the
ODBC SQLGetInfo function return feature information such as whether a DBMS
supports outer joins, procedures, or specific SQL scalar functions.
The insper sample Java program uses simple data types. To use it as a model
for adaptive programs, you need to modify the code so that it doesn't presume
specific type names to use with the CREATE TABLE statement. ODBC includes the
SQLGetTypeInfo function, which will report the available types for a data source
and the native name for a type. The native name is the string you need to use in
SQL statements. JDBC includes metadata classes that provide runtime reporting of
types and other column information.
Multitier Applications
The Java database picture isn't complete without looking at distributed
objects and three-tier applications. To better serve several concurrent users,
developers are partitioning the logic of SQL client/server applications by
moving business rules and non-GUI logic to application servers. VB and Visual
C++ (VC++) use automation interfaces and the Distributed Component Object Model
(DCOM) to support this model for distributed applications (for information about
DCOM, see the sidebar, "DCOM in NT 5.0: Strategic Enhancements," by
Keith Pleas, page 76). Java's approach to distributed objects is twofold, and
each alternative has its supporters. Sun Microsystems's APIs let Java programs
invoke methods on remote servers and work with distributed objects that conform
to the Object Management Group's Common Object Request Broker Architecture
(CORBA).
Microsoft's Visual J++ (VJ++) and Java Software Developer's Kit (SDK) use
DCOM and ActiveX, although they will support Java 1.1 APIs that work with CORBA
objects. Sun Microsystems has a solution, Java Beans, that exposes a uniform
component model that encapsulates heterogeneous components such as ActiveX and
OpenDoc. Beans will run inside Java programs and ActiveX and OLE containers.
Java licensees, including Microsoft, support JDBC and the other Java 1.1 APIs,
but Microsoft sees DCOM, Object Linking and Embedding (OLE) DB, Active Data
Object (ADO), and the new Microsoft Transaction Server as preferred solutions
for multitier development.
Performance is an issue when you're executing Java bytecode, and compiler
vendors have improved performance. Performance improvements, availability for
most OSs, the ability to work with multidatabase APIs, and a three-tier
architecture make Java an important database programming tool.
The ODBC and JDBC SQL APIs provide Java data access for multiple operating
systems. If you are writing solely for NT and Windows 95, you can also use Data
Access Objects (DAOs), Remote Data Objects (RDOs), and ADOs. With OLE DB, ADO
provides connectivity to SQL and non-SQL data. Those APIs offer the advantage of
being available for VJ++, VB, and VC++. However, unlike JDBC and ODBC, these
APIs are not supported for the writing programs on Macintosh, Solaris, OS/2, and
other environments.
The complete source and executable code is available for downloading from
Windows NT Magazine's Web site at http://www.winntmag.com.