On 2002.11.05 18:04:18 -0500 Rick Fincher wrote:

> 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.

I think this is more or less accurate except that jndi and xml don't have
anything to do with each other. JBoss has a xml based deployment system
that can result in things specified in xml being bound in jndi, but it's
not a direct mapping. Also ejb xml deployment descriptors define several
items to be bound in jndi.

>
> >
> > 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?

It's been a very long time since I looked at the protocol fishing code, and
I think we didn't port it, just assuming the latest remote protocol
version. We may have to revisit this when we up the protocol version.

Also I think the driver is highly biased towards dialect 3: I don't know
what happens if you use it with a dialect 1 db.

david jencks

>
> >
> > 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
> >
> >
> >
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>