At 03:42 PM 11/5/2002 -0500, Rick Fincher wrote:

>JayBird is also what is called a JCA driver. JCA stands for J2EE
>Connectivity Architecture. JCA is a specification that defines how
>databases are connected to Java 2 Enterprise Edition (J2EE) servers.

So far, so good.

>J2EE provides a framework for providing Portal and Web Services. It handles
>things like single sign-on login,

OK, I think I understand. The user logs into an application
and doesn't need to login to each part separately - no separate
database login, for example. That makes good sense.

>security

How does Jaybird interact with Firebird security (sic)?

>code sharing,

I know several different meanings for the combination of the
words "code" and "sharing". What does it mean in the J2EE context?

>HTML servers

Unh... OK, those sound like good things. What are they and
what is their significance to Jaybird? How do they relate to
JSP and servlets? and how do those relate to Jaybird?

>Enterprise Java Beans (reusable code)

What's the relationship between Java, Java Beans, and
Enterprise Java Beans? Does JavaScript have anything to
do with this - other than having the letters 'J', 'a',
'v', & 'a' in the name?

>database storage, and

That one I think I understand.

>data translation services

And how does that relate to Jaybird? Is it data
translation in the human language sense (American
to English) or in the computer architecture sense
(big endian, little endian) or ...?

>Since JayBird provides JCA support it can be used to connect Firebird to
>enterprise servers like JBoss, Websphere, Webgain, etc.

That sounds good... though my confusion about some of
the features above makes

> Firebird can be the database the server uses to store
>usernames and passwords,

??? I'm sure this is a great idea and that someone has
worried about making this stuff secure and all...

> user configuration settings,
>persistent sessions, object storage, as well as traditional
>database info. Many J2EE servers ship with an SQL database
>written in Java, or which has minimal capabilities. By using
>Firebird as the database, server performance can be dramatically
>improved.

Ah. That part I follow.

>JayBird also has built-in connection pooling. Setting up and tearing down
>the connections to a network database are time consuming tasks for a Java
>program. In a server environment with large numbers of logons, this can be
>a real performance bottleneck.

Got it. As long as something else is handling data security,
that seems fine. And as long as whoever does that remembers
that the database can be accessed by tools like ISQL and makes
provision to lock them out...

>Performance can be markedly improved by pooling the connections.

No question, as long as you don't need user identification associated
with the connection.

Please bear with me - I'm really not as much of an idiot as I
pretend - or maybe I am - but so much of the higher level stuff
that floats around (.NET being a prime example) turns out to
have lots of nice sounding words and very little hard reality
(and what reality it has tends to be very hard indeed)... I
can just nod my head and say, "sure, why not, sounds good..."
but I hope I get to explain the value of Jaybird to some fairly
hard-headed people and want to be prepared for their questions.

Anecdote, having little to do with the issue at hand, which the
reader is certainly allowed to skip. I am ancient enough that
I became a programmer by hanging around a place where programming
was done. In the very early days of my apprenticeship, I was
asked to review a text editor that DEC was developing for "non-
technical" computer users. My first test caused the editor to
crash a time-sharing development system, used by about 20
operating system and compiler developers. They were annoyed,
to say the least, so I was encouraged to focus on the documentation.
The first chapter discussed setting up text buffers. I wrote in
the margin "What's a text buffer? Something used to polish text?".
The writer threw a hissy fit. I was exiled to the COBOL compiler
development group. There's very little ambiguity about COBOL.


Regards,

Ann
www.ibphoenix.com