Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

The center of the universe is a database

Java and its role in the corporate database

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

Page 2 of 3

Importantly, JDBC is designed to insure that its API fits easily with existing APIs like ODBC. JavaSoft is working closely with a number of database vendors and tools suppliers (such as Intersolv) to provide bridges between the two standards. However, ODBC is not the only standard that may be supported via JDBC. Database-specific interfaces from Oracle, Sybase, and IBM, among others, will undoubtedly be written for applications that must coexist with existing applications, or in cases in which performance is of primary concern. Similarly, JDBC interfaces will evolve for network interfaces to enable access to multiple databases on different servers.

Today many people think of Java as a language for building applets that are downloaded to and executed by browsers, but its database API has been designed for much larger, more sophisticated applications. JDBC provides for the concept of database access applets. It lets developers distinguish between trusted and untrusted applets. Untrusted applets are typical in an Internet scenario in which information is transferred across insecure boundaries. Untrusted applets face a particular set of challenges in that they must execute in the "sandbox" of the Java Virtual Machine (JVM), from which there is no access to -- and frequently no knowledge of -- the local client's systems resources. Communications between databases and Internet applets also face an unknown latency as requests are routed across an ever-changing network topology to a server that may be in the next room or on the next continent.

JDBC presupposes that Java will be used in other application scenarios. As such, the API is designed to manage data access where code is trusted and is permitted to access local or network resources (beyond a specific URL) to read and write files and open network connections. To succeed as a language and as an interface, Java and JDBC must provide a solution to developers who write these mission-critical database applications. In a typical intranet scenario, developers may use Java to build multiple applications on which access to a single database is both common and essential.

JDBC is also designed to provide a natural implementation platform for N-tier client/server environments. In this scenario, a Java application may make a call to a middleware layer of services, which in turn accesses databases. These calls may be made through mechanisms such as a remote procedure call (RPC), an object request broker, or -- dare we say it -- OLE. Multitier database implementations provide an additional layer of security, performance, and management for database administrators by providing mediated access to specific databases where caching or local business rules may be implemented as needed.

An alternative solution

While JDBC holds great promise for database applications built in Java, it isn't quite there yet. Developers who need to implement an application immediately have a clever alternative. As long as there is a non-Java program on the server to handle the basic details of database interface, existing APIs like ODBC can be used with Java applets without recourse to any other interface.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources