Hi,

I apologize for quoting this long message, however I wanted everyone to be
able to refer to Jim's explanation without hours of searching.


I'm about to start working on some actual jdbc driver functionality based
on Alejandro Alberola Arias' gds implementation, and I have some perhaps
philosophical design questions.

1. We should eventually implement a java y-valve, right? I am thinking
that this might go well with using Catalog to indicate which database to
connect to (maybe).

2. The current implementation appears to me to put all externally visible
functionality in one class, GDS[_Impl]. I am wondering if it would be a
good idea to move the functionality that does not interact with the Y-valve
into other classes: then GDS would expose only functions that the y-valve
needs to implement, and the y-valve would have less to transfer to the
remote interface. Obviously we will no longer be working with a straight
java translation of the existing gds calls, but this might be fine. Also
the java y-valve will have the same interface as only one of the Remote
Interface objects: the other objects don't even need to go through the y
valve (have calls wrapped by the y valve layer), since they were obtained
from a connection to a particular database, they no longer need routing.

3. The current implementation, again following its c source, reports
problems using returned error codes. I think it might be a good idea to
replace this with exceptions.

So, I'd like some opinions before I get too far along in a possibly flawed
approach.

Thanks
David Jencks

On 2001.04.25 15:07:07 -0400 Jim Starkey wrote:
> At 04:09 AM 4/26/01 +1000, Mark O'Donohue wrote:
> >
> > One thought I had was to in your design to build a common front end
> that
> > uses a general interface to connect to the server process (say for
> > discussion here DBEngineConnectionInterface) one implementation allows
> > (DBSocketEngineConnection) which
> > talks natively to a remote FB/IB database.
> > It then allows for another implementation (DBJNIEngineConnection) that
> > connect to the engine and databse on the same
> > machine without going through a socket layer.
>
> I would like to quibble with your nomenclature on architectural
> grounds. During the Borland years much of the overall architecture
> has been lost (or at least misplaced) with regard to what is
> engine, what is server, and what is plumbing. The original
> architecture, though muddled, is still in place in the code,
> though not in the build. Since it is clear to me that
> a) Firebird and Interbase are going to diverge, and
> b) interoperability is essential, the original architecture
> is as important as ever. Let's start by clearing up the
> nomenclature.
>
> The general path from an application program to the engine
> is this:
>
> Application
> ----------------
> Y-Valve
> ----------------
> Remote interface
> ----------------
> (line protocol)
> ----------------
> Remote server
> ----------------
> Y-Valve
> ----------------
> Engine
>
> The Remote interface, Y-valves, and Engine have isomorphic
> interfaces.
>
> Database attachment works line this:
>
> 1. The application calls isc_attach_database, which is
> fielded by the local Y-valve.
>
> 2. The Y-valve polls its subsystems (a remote interface
> per network type plus an option "classic" engine) to
> see if any can make the attachment.
>
> 3. A remote interface module (typically TCP) recognizes
> a reference to a remote server (which may be on the
> same system). The remote interface strips off the
> node name from the database attach string and send it
> as and the database parameter block across the wire
> to the remote server.
>
> 4. The remote interface creates a network connection to
> a remote server (mechanism is irrelevant). The collects
> its arguments -- connect string and dpm -- an issues
> a isc_attach_database against its local Y-valve.
>
> 5. The (remote) Y-valve polls its subsystems (an engine,
> possible an version n-1 engine, possibly an engine
> from the other camp, and remote interfaces) to see if
> any can make the attachment.
>
> 6. The (remote) engine recogizes a file name (or soon a
> database name) that it understands. The engine creates
> an attachment (whatever that means to the engine) and
> returns a "handle" for the attachment to its caller,
> the (remote) Y-valve.
>
> 7. The (remote) Y-valve encapsulates the handle from the
> subsystem with an indication of which subsystem ponied
> up, and returns a handle to the encapsulation to its
> caller, the remote server.
>
> 8. The remote server takes note of the handle returned by
> the Y-valve for future reference, and returns "success"
> and a handle to the remote interface at the other end
> of the network connection.
>
> 9. The remote interface picks up the handle from the remote
> server off the wire, encapsulates it, and returns a
> handle to its caller, the (local) Y-valve.
>
> 10. The (local) Y-valve encapsulates the handle from the
> subsystem with an indication of which subsystem ponied
> up, and returns a handle to the encapsulation to its
> caller, the application.
>
> The important parts of the architecture are:
>
> 1. The engine doesn't know anything about the network.
> 2. The server doesn't know anything about engines.
> 3. The Y-valves don't know anything about either networks
> or engines, only an open-ended set of polymorphic subsystems.
>
> The plumbing components (Y-valve, remote interface, remote server)
> tranparently route calls and return results. Engines actually
> execute the calls.
>
> Please note that the architecture is open. New engines, networks,
> and protocols can be phased in, coexisting peacefully with existing
> components.
>
> "DBEngineConnectionInterface" implies that it making a connection
> to an engine. It isn't. It is making a connection to a remote
> server which calls a Y-valve which (maybe) calls an engine. Or
> maybe goes remote on a different network. Or maybe calls a gateway
> to Oracle.
>
> An essential step for Firebird to pry loose the server module,
> the Y-valve, and the engine(s) into separate images to restore
> the open architecture to allow Firebird 2 to coexist with Firebird
> 1 and Interbase 6 (if they ever get it working). Then the
> real fun of alternative protocols, gateways, and experimental
> engine can begin.
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Java-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>