Hi Ann,

I'm going to keep posting this on Firebird-Java so more knowlegable folks
can make corrections. If it gets onerous we'll go offline.

See responses below.

Rick

----- Original Message -----

> Rick,
>
> If this is terrifically boring to everyone else,
> perhaps we should take it off list. OK, let me see if
> I understand.
>
>
> JDBC drivers are designed to run against a specific
> database (Firebird, Oracle, Watcomm, Access, Postgres, etc.)
> In theory, give or take such things as how databases
> are addressed (i.e. connection strings) a Java program
> should be able to connect to any conforming JDBC driver
> and use it to access the database that driver was built
> for.
>
> OK so far?

Yes, correct.

>
> To make the theory a bit more realistic, there's a
> Java Naming and Directory Interface (JNDI) which is an
> XML protocol that describes the connection to the database,
> the driver name, and other important non-standards bits.
> Assuming the Java program and the driver support JNDI,
> the program can be blissfully unaware of what's on the
> other end.
>
> OK? 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.

If the Java program is compiled with the JNDI info, it uses the data in the
XML config file to find and load the driver and open connections rather than
using strings and driver names hard coded in the program. That way you can
change the XML config file and run with a different database without
recompiling. Assuming that the SQL commands you use work with both.

You can even stick the SQL strings (or even strings of a non-SQL protocol)
in the config file if you want and build up the final command string in the
program. That way you could work around syntax differences of different
databases.

>
> Types. There were once upon a time, one imagines,
> type 2, type 1, and perhaps type 0 drivers. The "typeness"
> refers to the way the driver connects to the database code.
> Ignoring (or being ignorant of types 0, 1, 2), let me echo
> back that type 3 (Interclient) is an "impure" solution and
> uses native methods to communicate. (sorry about the lousy
> arrows)
>
> Java program
> |
> V
> JDBC driver database server
> | ^
> V |
> native client side thing -> native server side thing
>
>
> A type 4 driver is all Java right to the wire
>
> Java program database server
> | ^
> V |
> JayBird -> ?????
>
>
> What does the communication on the server side for Jaybird?
> Is JayBird speaking the same wire protocol as other remote
> clients? Have we (finally) got some sort of rational way
> of checking remote protocol versions?

Type 1 drivers are a bridge to ODBC drivers. They can take advantage of all
the ODBC drivers out there.

Type 2 use native libraries on a system to work (more on native below). A
type 2 driver might call a C library to get the data.

Type 3 and 4 are pure Java and aren't dependent on other non-Java drivers or
Libraries.

A type 3 or 4 driver doesn't use anything, other than the driver, on the
client side. This makes them OS independent. Type 3 uses the API of the
middleware on the server. Type 4 talks directly to the database on its TCP
port, 3050 for Firebird/Interbase.

For example, Type 3 Interclient on the client makes calls to Interserver on
the server using whatever format Interserver is expecting on TCP port 3060.
Interserver then talks to Interbase on port 3050. Sometimes the middleware
provides services like security, or caching. Interserver encodes passwords
for some level of security, for example.

Type 3 drivers are presumably easier to write since the middleware can take
care of a lot of the ugly details.

JayBird, a type 4 driver, makes calls directly to Firebird on port 3050,
using whatever API Firebird expects. I presume this takes a lot more
knowlege about the nitty-gritty of how the DB works.

That's one of the nice things about Java, it has all the facilities for
opening network sockets and sending data built in. It makes networking
programs a lot easier.

I'm not quite sure what you mean about checking remote protocol versions.
If you mean, "Can the database query the client to see what protocol version
it supports?" I would think that would be doable as part of the initial
handshaking. I don't know if it is currently set up for that, but it could
be added.

Maybe David or Roman can answer that?

>
> More tomorrow.
>
> One last question. Why do Java people refer to non-Java
> code as "native"? Gives me the impression of men in white
> suits and pith helmets, passing out Eurasian diseases.
> Being a more botanical type, I think of native as "tough",
> "well adapted to the locale", "xerotic", and "having small
> boring flowers".

Java compiles to byte code that is not in the "native" machine code of the
host. The class files of byte code are OS independent. They are the same
on a Solaris system or a Windows system. To run any Java program on a
particular system and OS, you have to write a Java virtual machine (JVM)
that converts the byte code to native machine code and OS calls on the fly.
So Java is actually executed interpretively, even though the source code is
compiled into byte code.


>
>
> Regards,
>
> Ann
>
>
>