Java Database Connectivity Without Compromise

Imagine your corporate I.S. system being written in Java and usable by all employees irrespective of individual, departmental, or divisional preferences for Graphical User Interfaces, or Computer Hardware (PCs, Notebooks, Palmtops, PDAs etc.). Then, imagine embarking on a corporate Internet/Intranet/Extranet project with none of these restrictions. This is what makes Java so compelling and certainly why it has caught the attention and imagination of developers and end-users alike worldwide.

A secondary proposition is the development of ?Zero Admin? Java applications and Applets. Picture being able to notify every user of your corporate I.S. system about systems revisions or enhancements by simply sending them a URL (Uniform Resource Locator) to the new version of the I.S. system. The cost savings would be phenomenal to say the very least.

A comprehensive white paper explaining the Java value proposition can be obtained by pointing your Web Browser to the following URL: http://www.sun.com/javacomputing/whpaper/ch1_overview.html

Its Implementation & Architecture

Java is implemented through a Virtual Machine (VM). A Virtual Machine is a software implementation of a computer (sort of) that runs within a host operating system, running on an actual computer device. You might also want to refer to this as the Runtime environment for Java Applications (Apps.). & Applets.

The Java VM (JVM) is written in a combination of ?C? and Java (some Assembler code has also made its way into more recent releases). Java Apps. & Applets are compiled into Java Bytecode during development and executed within the JVM, which plays the role of Byte code interpreter. Java Byte code is a machine independent intermediary machine code format. This machine code format isn?t device specific hence the JVMs much vaunted platform independence.

Java objects are built using Java classes, and these classes are the compiled end product of Java class interface definition and implementations (contained in Java Language source code files).

Java Object Assembly Steps For "HelloWorldObject" Java Object

1.	Source File extract (File name is HelloWorldObject.java)
	Import java.*
	Class HelloWorldObject { Public static void main(String[] args) { System.out.println("Hello World!!!");
	} }
2.	Compilation of Source File (from host operating system command line) javac HelloWorldObject.java
3.	Java Class File Produced HelloWorldObject.class
4.	Execution of Java Application (Command Line Object instantiation) java HelloWorldObject

Java Applications, Applets, and Beans are typically comprise numerous other Java Objects working in concert through an Object messaging protocol (nothing to do with messaging communications middleware). A Java developer typically constructs his or her own Objects or incorporates those of others. Once constructed, the developer then devices a messaging protocol between these objects. This is what the end-user experience as a Java Application, Applet, or Bean.

Additional information on Object Oriented Programming Languages and concepts can be obtained by visiting the following URL: http://www.cgl.uwaterloo.ca/~anicolao/termpaper.html

Using Java

Applets

Applets do not live in a page as is commonly perceived. Applets are actually Java classes identified via HyperText Markup Langauge (HTML) tags within Web documents, it is these HTML tags that are embedded within Web documents. Java Applets are loaded from Web Servers somewhere on the Internet or within your corporate Intranet or Extranet.

Applications

Java applications fit the traditional application model in the sense that they are executed from a command line and need to be installed on, or migrated to, each application host machine and then executed within that machine?s JVM using the following command line construct:

java myappclass

Java Beans

A prefabricated Java component is known as a Java Bean. The Java Bean API provides a specification through which Java objects are fabricated (using the Java Beans Interface Specification) into component objects. These component objects are usable by Java Beans compliant container environments. Typical examples of such container environments include documents, application assembly environments, and other software component specifications (such as OpenDOC and ActiveX).

Java Beans facilitate the development and implementation of operating system independent prefabricated application components. These include graphical widgets, query engines, process engines, and full-blown applications, etc. To date, this has been an operating system specific experience as demonstrated with OpenDOC (predominantly MacOS & OS/2 based) and ActiveX (predominantly Windows based).

Note: Please bare in mind that software components do not have to be visible at runtime for them to fit into the definition of a ?Prefabricated Component?.

Java Class Migration Methods

The Java Virtual machine as explained earlier in this document, plays the role of execution environment for Java Objects. Thus, before any Java Application/Applet/Bean can be instantiated, their constituent classes must first make their way to the relevant Virtual Machine from which their services are to be consumed. (The process is described in this document as "Java Class Migration"). This process is one of the key elements that drive the perception of the Java in terms of performance and stability.

Java classes are typically migrated using one or more of the following methods: Web Servers & HTTP, "Push" based replication, or CORBA based Object Request Brokers (ORBs) using the Internet Inter Orb Protocol (IIOP).

Web Servers & HTTP

The Hyper Text Transport Protocol (HTTP) is an Internet protocol that addresses the transfer of files between Web Browsers (HTTP clients) and Web Servers (HTTP Servers).

Java Applets by their very nature are inextricably linked to HTML Documents and the HTTP file transfer protocol. This linkage exists because Applets are identified via HTML tags within these documents, and It is these HTML tags that instigate the Browser into sending an additional HTTP message to the relevant Web Server requesting a Java class file.

Stepping Through The Process

User enters URL string into browser e.g. http://oplweb.openlinksw.com/Demo
Browser pareses the URL and determines it is going to be using the HTTP protocol to request a document called "WebScrollDemo.htm", located within the directory called "Demo/JDK1.1", on a Server Machine named "oplweb", within the domain "openlinksw.com", running a Server process (the actual Web Server) that speaks HTTP.
The Web Server receives the files requested from the browser and then proceeds to locate the file called "WebScrollDemo.htm". Once located, it sends the file across the network to the requesting Browser.
The Browser on receiving the file "WebScrollDemo.htm" proceeds to process the HTML tags contained within the document :
<html>

<head>

<title>WebScrollDemo</title>

</head>

<body>

<hr>

<applet

code=WebScrollDemo.class

id=WebScrollDemo

width=600

height=400 >

</applet>

<hr>

<A HREF="WebScrollDemo.java" ><I>The Java Source</I></A>

</body>

</html>
The "<applet>" tag within this document indicates to the Browser that it needs to send another request to the Server Machine "oplweb" within the domain "openlinksw.com" requesting the file named "WebScrollDemo.class (actual Java Class).
The Web Server locates the file "WebScrollDemo.class" and then sends it back to the Browser.
The Browser on receiving the Java Class file executes it using its own version of the Java Virtual Machine.
User interacts with Java Applet

Disadvantages of HTTP

HTTP is insensitive to format of the files that it transfers, every file gets the same treatment.
HTTP is a stateless protocol, it doesn?t know or particularly care where you are in the processing cycle when using it.
It is a pretty simple protocol built to do very basic things.
It is inherently inefficient due to the fact that every response results in a new connection.

Advantages

HTTP is in wide use due to the popularity of Web Browsers.
HTTP facilitates centralization of resources such as Java Objects and HTML documents.

Push Technology

In response to some of the obvious shortcomings of HTTP an alternative approach to Java class migration has recently emerged, popularly known as "PUSH" Technology".

"PUSH" Technology (PT) involves intelligent caching and file replication schemes, whereby:

Java Byte code is copied to the host machine (a client in this instance) from a remote application server machine, and then cached (local copy is kept for subsequent use). Subsequent modifications to the applications classes are addressed by the server notifying the relevant JVM client about these changes, and then on obtaining approval from the client machine, it sends (the "PUSH" process) the updated application classes across the network to the appropriate client JVM.

PT products always involve client and server software components. And as a Java Byte code migration mechanism, can substantially increase the perceived performance of your Java App, as the class migration frequency between client and server is much lower in comparison to HTTP.

Advantages

Improved performance of Java Applications.
Removes dependency on Web Browser?s as a medium through which Java objects are utilized
Removes dependency on HTTP as the sole or dominant protocol for Java class migration.
It provides reduced administration, basically reinforcing the "Zero Admin" value proposition.
Java applications are centrally administered on the server and propagated out to requesting clients.

Disadvantages

A majority of "PUSH" Servers aren?t written in Java (at the time of writing none have been found), as a result the "Write Once, Run Anywhere" value proposition is compromised. The "PUSH" Servers out there today typically run on Solaris & Windows NT.
The client parts of a "PUSH" technology solution still need to be installed on each client seeking to use this technology, thus the "Zero Admin" is not really being achieved.
"PUSH" products can rapidly consume the limited disk resources currently available in today?s PC dominated Internet client world. It is a known fact that Internet client devices and local storage are looking to get smaller not larger.

Object Request Brokers

A few years ago the Object Management Group (OMG ? http://www.omg.org ) commenced work on the development and definition of a standard known as the Common Object Request Broker Architecture (CORBA). This is a very broad, powerful, and well defined standard that addresses the issues of locating, binding, and consuming Objects and the services that they provide in a Distributed Computing Environment. As we all know, the Internet ahs become the critical backbone of Distributed Computing, thereby accelerating the appreciation of CORBA compliant Object Request Brokers (ORBs)..

ORBs locate objects locally or across a network. Then, bind you to these objects, such that, when using these objects their physical location is insignificant to the consumer of these objects. An ORB is the most natural and coherent mechanism for locating and consuming Java Objects.

Today, we use the term "Web Browsing" to describe the experience of visiting a Web Site and viewing the contents of HTML documents stored on various Web Servers. Unfortunately, what we are really doing is "Web Fetching", because the documents we view are transferred via HTTP (see section on HTTP above) to the PC (or other Internet client devices) running our so called "Web Browser". The same applies when these HTML documents contain references to other data formats such as Java Applets, multimedia clips, etc.

In the future, the World Wide Web we know today will evolve into an "InterGalactic Object Web", and we will conduct true Web Browsing using ORBs that support the Internet Inter Orb Protocol (IIOP). A Web Site will become more like a dynamic multi-dimensional object-relational database, capable of storing the entire spectrum of usable human information. HTML documents and Java classes will no longer be migrated in their entirety to client Internet devices, thereby allowing, powerful servers to process a bulk of the work associated with these objects.

Advantages

Increased Performance and Resilience of Java based solutions due to reduced network hoops associated with Java class migration.
The "Write Once, Run Anywhere" value proposition is reinforced, as a majority of ORBs are being implemented in Java, and in situations where they aren?t written in Java, implementations already exist for all major operating environments. CORBA is much broader than Java and is language independent. Thus, COBRA allows the Object Web to be comprised of objects built using a variety of Object Oriented Programming Languages.
IIOP is a stated oriented protocol unlike HTTP, implying Distributed Java solutions can be implemented without compromising resilience or sophistication.

Disadvantages

Although IIOP has become the defining standard for Inter-ORB communication, a majority of implementations from different vendors remain incompatible.
ORBs are still in a majority require a fair degree of administration, but this will change as Java Orblets (the client or proxying element of an ORB) become common place.

Java Trouble Spots

Java Development Kit (JDK) version incompatibility & cross platform availability

Java is made available to users via the JDK, in recent times this has been upgraded from version 1.02 (Commercial Release) to 1.02 beta (with the addition of JDBC), to a 1.1 beta (releases 2 & 3), and finally to the commercial release of JDK 1.1. As you can imagine, Java compliant applications and environments haven?t kept up with this frenzied pace.

The "Write Once, Run Anywhere" value proposition is JDK version specific, today this applies primarily to JDK 1.02 as it is the most widely implemented version of the JDK, unfortunately the more exciting and mature aspects of Java reside in the version 1.1 JVM.

Java Class Migration

HTTP was primarily built to handle document migration, not application state management, which is a vital element when utilizing or writing, even moderately sophisticated application. Therefore, HTTP is not the foundation around which you want to build enterprise wide business systems. Of course, applets can make a strong claim in the "Zero Admin" proposition space, and they are written once and will run anywhere but, in what "STATE" remains the bigger and certainly more important question.

"PUSH" Technologies typically requires a client and a server piece, they are typically not written in Java which means they potentially compromise the Java value proposition unless, they are ported to all major operating environments. These products have an administration overhead potentially compromising Java?s other important value proposition, "Zero Admin".

Object Request Brokers like TV remote controls may not work with Objects from other manufacturers. Imagine being forced to buy both the TV and the remote control from the same vendor. This is great for the vendor, but a pathetic situation for the consumer. Luckily, there are Generic remote controls out there today in the consumer electronics world and Generic ORBs are certainly on their way, too (this is basically what IIOP facilitates).

Java DataBase Connectivity (JDBC)

What is it ?

JDBC is a database independent API that facilitates the development of database independent Java Applications/Applets/Beans. It is a Java abstraction layer that is based on the X/Open SAG CLI specification.

The JDBC Value Proposition

This is simply, "Write your Java Applications, Applets, and Beans Independent of Database Once & Run Anywhere".

The potential of JDBC in a Java dominated Distributed Computing World is only limited by the boundaries of our individual imaginations.

Architecture

Drivers for JDBC? are exposed to JDBC compliant Java Applications via the JDBC Driver Manager.

The JDBC Driver Manager is a Java Class Implementation, this means it is a interface used by JDBC service consumers (Application/Applet/Bean developers) and services providers (JDBC Driver Developers). The JDBC Application developers call upon the JDBC Driver Manager for JDBC Driver association (or Binding), JDBC Driver developers build the JDBC classes to the specification as depicted by the JDBC Driver Manager Class Implementation.

Driver Formats

Drivers for JDBC? fall into four main categories:

Driver Type 1 for JDBC?

The JDBC-ODBC bridge provides JDBC access via most ODBC drivers. Note that some ODBC binary code and in many cases database client code must be loaded on each client machine that uses this driver. This kind of driver is most appropriate on a corporate network, or for application server code written in Java in using 3-tier architecture.

Advantages

If an organization has made an enterprise wide commitment to ODBC as its data access standard, then this JDBC Driver format will simply fit into the existing infrastructure.

Disadvantages

It compromises the "Write Once, Run Anywhere" value proposition, ODBC is a Microsoft operating system specific database connectivity standard. The JDBC-ODBC bridge is implemented using "Native Methods" (operating system specific calls ).
This approach forces a 3-tier architecture on organizations in which the middle tier must be a Windows NT or Windows 95 machine, should you attempt to implement your solutions as Java Applets.
The "Zero Admin" value proposition is also compromised, as ODBC Drivers, and ODBC-JDBC bridging software (and in some cases additional expensive DBMS vendor provided networking software) need to be installed and configured in addition to the JDBC Drivers on each client machine.
JDBC Driver performance and sophistication is solely dependent on the performance of the underlying ODBC Driver.
This ultimately a very expensive approach to JDBC both in tangible (actual and hidden networking product costs) and intangible (administration, training, implementation) terms.

Driver Type 2 for JDBC

A native Application Programming Interface (API e.g. Oracle OCI or Sybase Open Client) and partly-Java based driver that implements JDBC Driver classes via Native Methods, these methods are typically direct bridges to the ?C? based Call Level Interface of the relevant Database Engine, and as such do not require the intermediary layer provided by ODBC Drivers .

This Driver format requires the relevant Database vendor?s CLI Libraries and Native bridge libraries to be installed on each client making use of JDBC compliant Applications/Applets/Beans, as these libraries (e.g. DLL files under Windows based operating environments) are not transportable over HTTP. Examples of the middleware required on each machine are : SQL*Net for Oracle, Open Client for Sybase, I-Net for Informix, Ingres Net for CA-Ingres, Progress Client Networking for PROGRESS, NETLIB for MS SQL Server, DDCS for DB/2 etc.

Advantages

If an organization has made an enterprise wide commitment to a single database engine, and also subscribes to the "ODBC is Slow" opinion, then this JDBC Driver format will simply fit into the existing infrastructure (Native Driver based).

Disadvantages

It compromises the "Write Once, Run Anywhere" value proposition, database vendor CLIs provide "Zero Database Independence" . The JDBC-Native Bridge is implemented using Native Methods.
This approach forces a 3-tier architecture on organizations in which the middle tier must be a machine running database specific networking software (the hidden high cost element), should you attempt to implement your solutions as Java Applets.
JDBC Driver performance & sophistication is solely dependent on the performance of the underlying Native Driver and its database specific networking software.
This ultimately a very expensive approach to JDBC both in tangible (actual and hidden product costs) and intangible (administration, training, implementation) terms.

Driver Type 3 (Format A) for JDBC

A net-protocol all-Java driver translates JDBC calls into a DBMS-independent network protocol that is then translated to a DBMS protocol by a server. This net server middleware is able to connect all itsJava clients to many different databases. The specific protocol used depends on the vendor. In general, this is the most flexible and "OPEN" JDBC alternative. It is likely that all vendors of this solution will provide products suitable for Intranet use. In order for these products to also support Internet access they must handle the additional requirements for security, access through firewalls, etc., that the Web imposes. Several vendors are adding JDBC drivers to their existing database middleware products.

Driver Type 3 (Format B) for JDBC

This JDBC Driver format differs from the previous architecture, based on the "across the wire" data protocol in use being JDBC as opposed to ODBC based.

Advantages

Reinforces the "Write Once, Run Anywhere" Java value proposition. This is a Generic format in which the JDBC Driver contains no Native Methods, and isn?t bound inextricably to alternative data access standards such as ODBC or database specific networking software provided by database vendors.
Facilitates the implementation of JDBC compliant Applets without a 3-tier architecture, thereby reinforcing the "Zero Admin" Java value proposition.
Performance & Sophistication become sole features of the JDBC Driver as opposed to underlying dependencies on the capabilities of ODBC or database specific networking software.
Reinforces the JDBC value proposition by enabling the development of database independent Java Applications/Applets/Beans.
This is a very cost-effective way to implement JDBC within the Internet/Intranet/Extranet.

Disadvantages

Performance & Sophistication (security, configuration management etc.) depend on the underlying capabilities of the database independent networking aspects of the JDBC Driver. If this is slow or unsophisticated, then the perception of the JDBC experience within your organization will also be slow and unsophisticated albeit independent of underlying database.
An ODBC based "across the wire" protocol or a JDBC server component that is totally ODBC based ultimately limits the scope of JDBC Drivers to those of the underlying ODBC Drivers. This ultimately, once disentangled, compromises the "Write Once, Run Anywhere" Java value proposition.

Driver Type 4 for JDBC

A native-protocol all-Java driver converts JDBC calls into the network protocol used by DBMSs directly. This allows a direct call from the client machine to the DBMS server and is a practical solution for Intranet access. Since many of these protocols are proprietary, the database vendors themselves will be the primary source for this style of driver. Several database vendors have these in progress.

Advantages

If an organization has made an enterprise wide commitment to a single database engine, and also subscribes to the notion that the database vendor should provide all relevant interfaces to the database, then this JDBC Driver format will simply fit into the existing infrastructure (Native Driver based).
It supports the implementation of "Zero Admin" JDBC compliant Applets.

Disadvantages

It compromises the Database Independence of JDBC in the sense that the behavior of a JDBC compliant Applications/Applets/Beans is far less predictable across different database engines, primarily in the area of JDBC API implementation, as opposed to, core database functionality (the right place to DBMS Engine to differentiate themselves).
JDBC Driver performance & sophistication is solely dependent on the performance of the underlying database specific protocol implemented in Java by the relevant DBMS vendor.
This is ultimately a very expensive approach to JDBC both in tangible (actual and hidden product costs) and intangible (administration, training, implementation) terms. The backend DBMS licensing will remain excruciatingly painful even though the front end JDBC Driver might initially appear to be very cost effective. JDBC like ODBC is about database engine commoditization and naturally most DBMS vendors will resist this for as long as the market remains unaware of this ulterior motive.
It attempts to perpetuate the soon to be obsolete the "One Stop Shop" mindset, amongst technology vendors and consumers.

JDBC Utilization Mechanics

In JDBC parlance a source of data is a resource, and since JDBC is an Internet centric data access mechanism, it is imperative that it emulates existing resource binding mechanisms used by other Internet protocols and technologies. JDBC drivers locate and bind to data sources via JDBC URLs, these take the following format :

<Protocol>:<Sub-protocol>:[<sub-name>]:[//<host name or address>[:port number]] [/Driver Attribute 1 ??./Driver Attribute n]

The URL structure above is driver dependent, in the sense that it is the driver?s responsibility to parse, and interpret those areas represented in square brackets. Thus, JDBC drivers provided by different JDBC driver vendors require different URL formats.

Example JDBC URLs

Sun?s JDBC-ODBC Bridge

The URL below will connect you to an ODBC Data Source Name (DSN) called "Accounts" that already exists on the machine from which this JDBC Driver is to be loaded (typically your PC):

jdbc:odbc:Accounts

OpenLink Software?s Driver for JDBC?

The URL below will connect you to a logical Data Source Name (DSN) called "Accounts" that already exists on a server machine (host name ? jupiter) from which this Driver for JDBC? is to be loaded:

jdbc:openlink://jupiter:5000/DSN=Accounts

JDBC Utilization Today

JDBC is currently used by Java Application and Applet developers to build Internet and Intranet based database independent Applications/Applets. The Applet classes are predominantly transported to the calling JVM via HTTP, while Application classes increasing make their way to the calling JVM via ?PUSH? technology products.

JDBC Utilization Tomorrow

The Java/CORBA juggernaut is gathering tremendous momentum, and in the coming year there is going to be a substantial shift to Object Request Broker (ORB) based binding to remote Java classes using the OMG?s IIOP protocol. ORB-IIOP based Java class binding will have a much smaller data transfer footprint than "PUSH" technology and none of the HTTP dependencies of Applets, without compromising Java & JDBC?s respective value propositions.

Javasoft has also provided an additional Java specific based remote binding and method execution mechanism called RMI (Remote Method Invocation), this is conceptually very similar to the ORB-IIOP approach but a Java only solution, whereas the ORB-IIOP standard binds you to a range of object implementations.

JDBC Trouble Spots (value proposition break points)

The JDBC value proposition is currently very vulnerable, and once compromised its relevance and usability will always come into question. These vulnerability or value proposition break points take many shapes and forms most of which are addressed in the sections below:

HTTP Dependence of Applets

JDBC Applets are currently the rage, we all want "Zero Admin" Java solutions that are independent of database, that we develop once and run anywhere. But, what does "Anywhere" really mean in this instance ? At the present time it means anywhere there is a HTTPD (Web Server) process running, with your JVM being a part of the Web Browser that you use to view the pages that host your JDBC compliant Applets.

JDBC is not part of JDK 1.02, and a majority of Java supporting Web Browsers (especially Netscape & MS Explorer) currently ship with the 1.02 JVM. Java support by a Browser vendor typically means the JDK 1.02 core classes are pre-installed on the Internet device (typically a PC today) in use. It also means that the Browser will not expect to load core Java classes from a remote server, irrespective of transport mechanism (HTTP or IIOP). Thus, attempts to load Applets that have been developed using core Java classes that are not part of the local JVM implementation are rejected and these rejections are communicated to you as "Applet Security Model" violations.

JDBC is part of the JDK 1.1, but as you can imagine the Browsers vendors are all currently working on JDK 1.1 based JVM implementations for their Browsers. Until JVM 1.1 Browsers make their way out of R&D it isn?t theoretically possible to for you to develop or use of JDBC compliant Java Applets.

?PUSH" Technologies

This is one of the ways in which the Browser and HTTP dependencies referred to above can be circumvented, but introduces its own set of value proposition break points.

These products are not written in Java on the server side so, writing once and running anywhere is more of a "Somewhere" type proposition.

These products subscribe to the concept of total object migration, as opposed to object referencing, they have no appreciation or understanding of matters such as physical disk real estate on the Internet device (they basically presume this is a PC with lots of disk space and memory). They certainly speed up the initialization time of your JDBC compliant Java application but don?t really preserve the value proposition.

Object Request Brokers (ORBS)

ORBs like real life brokers bind you to service providers, but like one of the most ubiquitous real life providers of all (Remote Controls), it does not migrate the service provider (TV set), or the actual service (the Program being viewed) in its it entirety to you. Instead, you remotely control and consume the service provided.

Java and ORBS are coming together at a frenzied pace, but question marks remain regarding cross ORB interoperability. The IIOP standard is a major step in the right direction with regards to addressing this problem but it still does not guarantee that Java objects and the ORBS that broker these objects are independent. Thus, it is safe to conclude that Java application developers currently have to write to numerous ORB interfaces to pursue any possibilities of real ubiquity. This certainly breaks the Java and JDBC value proposition.

Very few ORBs are written in Java, this introduces yet another potential value proposition break point, as your Java objects might not have an ORB implementation for host operating environment in within which the JVM resides.

Performance

If JDBC Drivers do not deliver acceptable performance consistently across multiple platforms, and Database Engines, then once again the JDBC value proposition will be broken.

ODBC links

In recent times Microsoft?s Open Database Connectivity (ODBC) standard and JDBC have become inextricably linked for the wrong reasons. Of course it is important that JDBC Drivers are able to exploit the plethora of ODBC Drivers available today, but it isn?t mandatory that ODBC must be in the mix when dealing with JDBC. Unfortunately a majority of the current JDBC technology adopters fail to see, or more importantly understand the impact of this misconception.

ODBC is a operating environment specific, it was devised with Windows in mind and that?s it, although implementations on other platforms exist, tangible use outside of the Microsoft Operating System space has been sparse to say the very least.

Inextricably linking ODBC with JDBC certainly breaks the JDBC value proposition.

Record Scrolling & Data Sensitivity

JDBC unlike it operating system specific counterpart ODBC, currently lacks the ability to scroll through records. The JDBC Record Set Object only has a ?Next? method. This is a gapping hole in the JDBC definition itself and makes it practically unusable for the development of data sensitive enterprise wide solutions. Currently most JDBC developers and driver vendors implement scrolling capabilities by abstracting above the base JDBC level, while others attempt to use the Embedded SQL hooks provided by the specification for locating Cursor Names etc. Unfortunately, this is approach is outdated and more importantly a far cry from the real solution.

If you cannot write sophisticated data sensitive JDBC compliant Applications/Applets/Beans then JDBC?s use becomes much reduced.

JDBC developers & users cannot be expected to ultimately enjoy writing or using JDBC solutions, that only deliver on the core JDBC value proposition, if data access elements of their solutions are "STATIC" in nature? The world is becoming a smaller and more dynamic place everyday, driven primarily by the Information revolution and connected global market place, both of which are driven by access and manipulation of "DYNAMIC" data.

Proxying & Security

The Internet, Intranet, and Extranets define three of today?s TCP/IP dominated Distributed Computing Formats. The Internet being the all-encompassing infrastructure, Intranets being that segment of the Internet behind a corporate firewall, and the Extranet being portions of the Intranet exposed to the wider Internet.

To use JDBC Drivers within any of the distributed computing formats mentioned above, these Drivers must be capable of providing access to databases behind corporate Firewalls, but when they do so it cannot be at the expense of security. JDBC Drivers possessing Proxying capabilities addresses this requirement.

If JDBC Drivers are not usable within the Internet, Intranets, and Extranets, then the JDBC value proposition will be broken.

User and Organization Diversity

One of the greatest weaknesses of any technology is its failure to anticipate diversity among its consumers. For instance, it is no secret that within organizations we have a range of computer skill levels, and these typically transcend departments and divisions. It is also no secret that even if we were all computer technology wizards, the very existence of our employing organizations would rest not on the chaotic application of our wizardry, but on the orderly application of this wizardry through coherent development, acquisition, and application of the organizations business systems.

JDBC must allow the development of applications that appreciate user diversity within an organization, without this capability JDBC Applications/Applets/Beans become inherently inflexible due to fixed assumptions about JDBC technology consumers.

JDBC must bind itself to the consuming organization logically as opposed to physically, as without this it inevitably breaks its value proposition.

OpenLink Generic High- Performance Drivers for JDBC?

What are they ?

OpenLink Generic High-Performance drivers for JDBC? provide transparent access to data sources from JDBC compliant Applications/Applets/Beans resident on the Internet or within Intranets or Extranets. They are an intergral part of the commercial offering known as the "OpenLink Data Access Drivers Suite".

The OpenLink Value Proposition for JDBC?

"Write Once Independent of Database and Run Anywhere, without compromising Usability, Security, Performance, or any aspects of the Java value proposition".

Implementation & Architecture

OpenLink Software provides Type 1, Type 2,and Type 3 Drivers for JDBC? . The Type 1 & 2 Drivers are integral parts of the "OpenLink Data Access Drivers Suite (Lite Edition)", while the Type 3 Drivers are integral parts of "OpenLink Data Access Drivers Suite (WorkGroup & Enterprise Editions)".

OpenLink Lite for JDBC? (Type 1 Driver for JDBC)

These are JDBC-ODBC bridged drivers, implying an inherent dependency on the existence, features and capabilities of the ODBC Driver Manger and ODBC Drivers installed on the machine hosting your JDBC compliant Applications/Applets/Beans.

The JDBC Driver classes are implemented via native methods, this implies that the methods implemented within the JDBC Driver are implemented via mappings to ?C? functions or ?C++? objects in a separate dynamic or shared library (depending on host operating system), these libraries are basically ODBC compliant service consumers (clients).

OpenLink Lite for JDBC? (Type 2 Driver for JDBC?)

These are JDBC-Native Database Interface bridged drivers, implying an inherent dependency on the existence, features and capabilities of the relevant database vendors client interface and database specific network middleware on the machine hosting your JDBC compliant Applications/Applets/Beans.

The JDBC Driver classes are implemented via native methods, this implies that the methods implemented within the JDBC Driver are implemented via mappings to ?C? functions or ?C++? objects in a separate dynamic or shared library (depending on host operating system). These libraries are built using the native call level interfaces of the relevant database server.

Figure 1 ? OpenLink Lite for JDBC? (Native Bridge for JDBC?)

OpenLink for JDBC?-ODBC Type 3 Drivers for JDBC? (Format A)

This is a Generic Driver implementation with the JDBC Driver methods written entirely in Java negating the need for Native methods. It is also a Multi -Tiered implementation that facilitates a very thin client layer implementation that also incorporates a Database Independent Networking Layer. This Driver format uses ODBC Drivers for its lower level data access services.

Figure 2 - OpenLink Generic Driver for JDBC? (Multi Tier Architecture ? ODBC Server)

OpenLink Drivers for JDBC? Type 3 (Format B Drivers)

This is a Generic Driver implementation with the JDBC Driver methods written entirely in Java negating the need for Native methods. It is also a Multi-Tiered implementation that facilitates a very thin client layer implementation that also incorporates a Database Independent Networking Layer. This Driver format uses Native Database drivers (OpenLink Database Agents) for its lower level data access services.

Figure 3 - OpenLink Generic Driver for JDBC? (Multi Tier Architecture ? Native Server)

Product Features

Blistering Performance ? Drivers use the same industry acclaimed high-performance database independent communications layer popularized by the OpenLink High-Performance ODBC Driver product set.
Multi Tier Architecture ? JDBC architecture?s modular nature enabled the implementation of a very thin client layer (Generic Driver) that is serviced by powerful server components.
Browser Independence ? JDBC Drivers can be used to develop JDBC compliant Applets independent of Web Browser, these can be JDK 1.02 or JDK 1.1 compliant .
JDK 1.02 & JDK 1.1 Compliance ? Drivers are available in formats that match each version of the JDK.
100% Java solution ? Generic JDBC Driver is written in Java, thereby supporting the development and utilization of JDBC compliant Applications/Applets/Beans wherever there is a Java Virtual Machine.
Scrollable Cursor Support ? Drivers contain an extended Result Set Java class that facilitates Bi -Directional Scrolling via JDBC.
Heterogeneous Database Support ? JDBC Driver is Generic providing concurrent access to multiple JDBC and if need be ODBC data sources.
In-built Proxying capabilities ? Drivers have in-built proxying capabilities which makes them capable of connecting to data sources behind a corporate firewall without violating security.
Sophisticated User Profiling ? Drivers have the ability to work within the confines of user or administrator definable profiles, thereby providing Logical Firewall features that bolster the physical security provided by Firewalls.

Product Benefits

Standards based ? Each component that makes up the OpenLink Multi Tier architecture for JDBC?adheres to industry standards., thereby preventing artificial technology lock-ins that are expensive to exit.
Transparent access to data sources ? The location, shape, and form of your data sources become irrelevant. In addition, the accessibility to data allows you to spend more time producing information as opposed to determining how to actually get at data.
Freedom to Mix & Match "Best of Class" products ? Freedom to select Java Applications/Applets/Beans that best suit your organization?s needs.
Maximum Incorporation with Minimum Disruption - Fits JDBC into your existing computing infrastructure
Preserves the JDBC value proposition: "Write Once Independent of Database & Run Anywhere".

Conclusions

Java has caught the imagination of the world, and for the right reasons gladly so, the JDBC and the Java Beans specification certainly bolster Java both technically and commercially, and finally the coming of age of CORBA ORBs and the IIOP protocol , applied in tandem with Java, basically set the scene for the next major quantum leap in IT:

The age of Inter-Galactic, Distributed, Component based Computing is neigh. Failure to accept or understand its potential and ramifications can only be detrimental to IT developers and end-users alike.

Anticipating the manifestation of this IT prophecy can only yield good things for your organization?s critical success factors ? Increased Profits, Reduced Staff Turnover, Leaner and Meaner Enterprises, Increased Freedom to Innovate on the part of software entrepreneurs, Improvements in Software Quality via componentization ? ultimately leading to much better returns on your IT investments !