> > > Does Jaybird do JNDI?
> >
> >JNDI is more or less a resource locator. It can be used with any object.
> >In this case with any JDBC driver. The driver is unaware of JNDI. The
> >program uses JNDI to find out which driver to load, where it is on the

disk

> >(or the net), what the connection parameters are, etc.
>
> Then I guess the question is: "does Jaybird publish JNDI
> descriptions of itself, or must the user intuit the values
> and create the descriptions?"

JayBird sort of does that with JCA, but that is only useful in the context
of a J2EE server. JNDI is more generalized. The programmer has to put the
particulars in the XML parameters files.

An example of a JNDI use of JayBird is with Tomcat. Tomcat is a JSP/Servlet
engine or server. JSP allows Java scripting in HTML pages to generate
dynamic HTML pages similar to Microsoft's ASP. Servlets can be thought of
as Java based cgi extensions for an HTML server. So Tomcat is a web server
that allows me to run extensions written in Java and allows me to serve up
dynamic HTML pages that change based on user input or whatever.

If I want my servlets and JSP's to be able to pull data in from a Firebird
database, I just drop my JayBird Java archive (jar) files in a certain
directory that Tomcat sets up for this purpose.

Then I go into the XML files that Tomcat uses for configuration and add
entries for Jaybird in the area set up for JNDI. Tomcat then uses JNDI to
set up my database as a named resource that is available to any web
application that the server runs.

Next I go into the setup file that each web application is required to have
(also an XML file) and put in an entry telling it the name of the JNDI entry
for the Jaybird Driver. Now my web apps get connections from this driver.
My web apps don't know what kind of driver it is, or even the name or type
of the database, they just know that they get a connection when they ask for
one and they can pass SQL commands to it and get result sets.

My apps do have to know details like column and table names, but I can pass
those as JNDI named resources too. The idea is to use the JNDI name in the
program and then assign the data to those JNDI resources using the setup
file.

I can change the table and column names used by the program by stopping
Tomcat, editing the config file, and restarting Tomcat.

This way I can write a web app and use Firebird with it, but I can also give
the same web app to a client that insists on using Oracle. No problem, drop
the Oracle JDBC driver in the appropriate directory, edit the setup file to
assign the Oracle JDBC driver, DB table names, and column names to the JNDI
resources and restart Tomcat.

The same web app now runs with Oracle. You don't have to change the web
app's config file because it is getting the driver and other info from
Tomcat using the JNDI name that you specified in the Tomcat config file.
You have just assigned the Oracle driver to that name instead of the
Firebird Driver.

It is similar to setting up a resource fork in a Macintosh program, if you
are familiar with that.

Believe it or not this actually works (usually) if you use least common
denominator SQL. Part of the reason for this is the JDBC interface. All the
differences in the various databases are cancelled out by their JDBC driver
because the spec requires that the data returned to the Java program be in a
specific format. If Firebird and Oracle store floating point numbers
differently, their JDBC drivers are responsible for converting them to the
JDBC standard format before passing them back to the Java program.

This results in the various JDBC drivers not supporting certain capabilities
of their database because the JDBC spec can't handle it. Sometimes the JDBC
driver implements these capabilities anyway, but using those features
sacrifices portability.

Then the programmer can choose between portability or capability.

>
> >Assuming that the SQL commands you use work with both.
>
> Which is unlikely. No, Ann, don't start on standards. It
> just gets you upset and antagonizes everyone else.
>
> >I'm not quite sure what you mean about checking remote protocol versions.
>
> What I meant is precisely a handshake thing where the client says
> "I speak protocols 2.1, 2.2, 3, 3.04, & 7". The server says "I
> speak protocols 3.2, 4, 5, & 7". We agree on 7 and off we go.
> However, in the past, the protocols have not been rigorously
> labeled, so there are sometimes several variants that claim
> be the same. What I'm advocating is strict adherence to protocol
> versioning and possibly documenting the differences between
> versions.
>