[JXTA discuss] Jxdbc, a JDBC proxy driver for JXTA, version 2005-04-18 released

Jxdbc, a JDBC proxy driver for JXTA.
http://jxdbc.jxta.org/files/documents/336/187/jxdbc-bin-20050418.zip

I. What is Jxdbc?

Jxdbc is a proxy JDBC driver for JXTA.

proxy: It forwards JDBC methods invocation from an application using
Jxdbc over JXTA.

The proxy is implemented as a client peer at one end of a JXTA secure
pipe and a server peer at the other.

The client peer is it self a server.

The application using the jxdbc driver communicates with the client
using an RMI Proxy.
The client forwards request and returns the results via this RMI Proxy.
The server carries out the requests and saves state between requests.
The driver is the most "intelligent" part and the client the "dumbest".

The introduction of the client peer allows the driver to totally
ignore the use of the JXTA API with the consequence that one can write,
compile and almost run Jxdbc applications just like normal JDBC
applications.

The driver can connect to one or more clients, a client can connect
to one or more servers, a server can connect to one or more databases.

Jxdbc is based on Jxta 2.3.2b

Bugs and resources are the only limits.


II. Usage of Jxdbc.

1) Server, client and application(s) on same computer:
For demonstration only, development, debugging and benchmarking.
Not the normal use.

2) Remote server, client and application(s) on same computer:
Normal scenario. Application(s) access(es) remote database(s)
via JXTA because of firewalls, dynamic addresses, NATs, etc.

3) Remote server, remote client, application(s) on this computer:
Same as above, in case IT department forbids the use of JXTA for
security reasons. Having server and client running under their
scrutiny might allow the use of JXTA under their strict supervision.

This also makes it possible to use Jxdbc on old and slow hardware
(e.g. on a 80MB/133MHz PC running Windows 95 and java 1.4.2_04).

4) New usage: Disconnecting the application (in this case a JDBC driver)
from
the peer has facilitated the development. JXTA is being used as a commodity
the same way TCP/IP is used today.


III. Bugs and limitations.

Too many bugs to be yet discovered.

The driver and supporting classes make no attempt to be operational with
other languages other than Java. The Jxdbc server features a generic server
based on JxtaSocketServer/JxtaSocket. The logic is implemented as commands
using the Command Design Pattern.

Jxdbc uses serialization of classes over jxtaSocket, an RMI ProxyFactory
and an RMI Proxy.

It does not use XML messages other than the one used by JxtaSocketServer
and JxtaSocket classes and the JXTA platform, of course.

This its stronger or weaker feature, depending on your opinion.

JDBC and RMI are java answers to programming problems, so I think
that this approach was justified here. However, I found it so easy
to programme that it will be very difficult for me not to work like
that again.


IV. Easy starting

1) Create a directory (e.g.: C:\jxdbc) and copy the files from
the archive into it. You will be using the scenario as described
in II.1.

2) Edit the environment variables in the different .bat files
to your liking.

3) Copy down the JDBC url and the driver of one of your favorite
databases.

4) Run the GenerateIDs.bat command file. This will start a
JXTA peer which by default uses the same setting as the JXTA peer
instantiated by the run_server.bat command file.
Configure the peer as usual.

The application will show in a window the content for a new
jxdbc.properties file.

5) Copy and paste the content of the window into a file called
jxdbc.properties.

6) The url for a Jxdbc database is: jdbc:jxdbc:<your database> where
<your database> is replaced by an identifier of your choice. if you
choose test as an identifier, then the url becomes jdbc:jxdbc:test.

There is a sample.jxdbc.properties file in the sample directory
for you to examine. You should not use it, but generated a new one
if you don't want to share your pipe advertisement with the entire
JXTA Planet who didn't followed this advice.

The fully qualified name of the driver is: be.loah.jxdbc.Driver.

Replace now <your database> by your chosen identifier,
<your group name> by a group name, your
<your database original url> by the original url and
<your database original driver> by the original driver fully
qualified name.

The jxdbc.properties must be placed in the directory from where
you start the JVM, e.g. in the directory where you put the .bat
command files.

7) Start the server by running the run_server.bat command file. Since
it uses the same setting as the program that you used to create your own
jxdbc.properties file, the server is already configured and almost ready
to answer a request from a client peer.

8) From the same directory, run the run_client.bat command file.
This will start a new peer.
Remember that the server and the client must not share the same port number
when running on the same machine.
Now the client is almost ready to forward JDBC request from an application
using this JDBC driver over JXTA.
The server peer and the client communicate over secure pipes, and since
JXTA 2.3.1, both end of the pipe must have validated each other.

9) On the server, click on the shell button to open a JXTA Shell window.
Locate the client with the following commands:
JXTA> peers -r -aName -v<the name of your client peer>
JXTA> peers -aName -v<the name of your client peer>
You will receive a list of one or more environment variables from peer0 to
peerN.
Locate your peer and run the following command:
JXTA>pse.importcert peerN

10) Do the same on the client. The server and the client have
validated each other and can now communicate over a secure pipe.

You are now ready to try the driver.


V. Using the driver

1) Put the jxdbc.jar file in your classpath.

2a)

  try
  {
   Class.forName("be.loah.jxdbc.Driver");
  } catch(ClassNotFoundException e)
    {
     System.err.println("Cannot find JDBC driver");
     System.exit(1);
    }
  Connection connection = DriverManager.getConnection("jdbc:jxdbc:test",
"sa", "");

  or

2b)

   DataSource dataSource = new
be.loah.jxdbc.driver.DataSource("jdbc:jxdbc:test");
   Connection connection = dataSource.getConnection("sa",null);

 or

2c)

I have used hsqldb 1.7.2 (http://hsqldb.sourceforge.net) which comes
with a tool to connect and execute SQL statement. I have put a
modified .bat command file in example\hsqldb\bin. Generate the proper
jxdbc.properties file first! To connect to hsqldb using their tool,
simply overwrite in the connect dialog box their driver with
"be.loah.jxdbc.Driver" and the url with
"jdbc:jxdbc:<whatever you have defined>

I have also added a test program in source using hsqldb so that you
can modify it to use with another database. The program uses
jdbc:jxdbc:test or jdbc:jxdbc:demo as url, so you'll have to use the
same url or modify the code. The test programme is included in the
jar file.


VI. Moving from scenario II.1 to II.2 and II.3

1) If you managed to run Jxdbc on one computer (scenario II.1), than you
will have no problem moving to scenario II.2 (remote server, client and
application(s) on same computer) or even II.3 (remote server, remote
client, application(s) on this computer).

2) Remote server, client and application(s) on same computer
Create a directory on the remote computer and copy the run_server.bat
command
file, the jxdbc.properties and the server\.jxta directory. This last step
will save you the trouble to customize a new peer that you will have to
validate and you will also have to validate the client. You can simplify
the jxdbc.properties file by removing section 1 and 2.

In this scenario, the driver is on the same machine as the client. By
default,
unless told otherwise by the jxdbc.properties files, it will connect via RMI
to localhost on port 1099. In this case, the driver does not need a
jxdbc.properties file at all.

3) Remote server, remote client, application(s) on this computer
Create a directory on the remote client computer and copy the run_client.bat
command file, the jxdbc.properties and the client\.jxta directory. This last
step will save you the trouble to customize a new peer that you will have to
validate and you will also have to validate the server. You can simplify the
jxdbc.properties file by removing section 1 and 3.

In this scenario, the driver is no longer the same machine as the client. By
default, unless told otherwise by the jxdbc.properties files, it will
connect
via RMI to localhost on port 1099. This is wrong. You need a
jxdbc.properties
file that gives him the location of the client, either by name or IP
address.
You can simplify the jxdbc.properties file by removing section 2 and 3.


VII. Feedback and comments

I welcome critics and praise alike. Please don't just say I like it or you
did
it wrong. Tell me what database are you proxying. If something is wrong,
tell
me what's wrong as well expected the result, value, behavior, etc.


VIII. Source code
Available soon.

Michel Polet


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]