
This tutorial walks you through the creation of a simple web service
that uses the Orinda demo database.
| Component |
Product/Version |
Obtained
From |
| Operating System | Windows XP, SP2 | Microsoft |
| Java Virtual Machine |
Java 1.4 (j2sdk1.4.2_04) | Sun Microsystems |
| Web Server |
Apache Tomcat/4.1.31 |
Apache Jakarta
Project |
| Oracle Database
Server |
V10.1.0.2. (on a different
machine) |
Oracle |
| JDBCWizard |
V5.0.2200 |
Orinda Software |
| Web Service Toolkit |
Apache Axis 1.1 (on developer's
PC) |
Apache Web Services Project |
| Java IDE |
Eclipse 3.0.2 |
Eclipse Foundation |
You don't have to exactly replicate this environment to use JDBCWizard to create Web Services. JDBCWizard does not have any dependencies on Apache Axis or Tomcat.
GRANT CONNECT, RESOURCE TO ORINDADEMO IDENTIFIED BY ORINDADEMO; CONNECT ORINDADEMO/ORINDADEMO@database_name; START orindabuild_demo_ddl.sql |
START
orindabuild_demo_dml.sql |
To access this database using JDBC we'll need to know the hostname/IP Address, the port Oracle's listener is running on and the database SID (instance identifier).

At this stage you should stop and restart tomcat and make sure that your Axis installation is working. Test this by entering the URL
in your web browser:http://localhost:8080/axis/index.html
Unzip the JDBCWizard demo to 'C:\JDBCWizard.emo'. For information on the demo see here.
Start JDBCWizard and log in to your database. In our case we used an Oracle 10.1 database called 'LX1010' located at the local IP address 192.168.0.30:

Click on the 'Select Objects" tab and select all the PL/SQL Stored Procedures:

Move to the "Sql Statements" tab. Change the SQL file path to 'C:\JDBCWizard.emo\demo\SqlFiles` and then press the 'Refresh ' button. The SQL statements in the SqlFiles directory should appear in the tree structure. Press the 'Select All...' button to include them in the Web Service code.

The "Tables" tab isn't used by Web Services. JDBCWizard will create a
Data Access Object Factory class to access the tables you select.
This screen controls how the generated code looks and behaves. Change the 'Target Version of Oracle' in step 3.3.5 so it's the same as your database and move on to step 4.


| Field |
Our
Value |
Comment |
| 4.1 - Enter root directory for
Java Code |
C:\JDBCWizard.emo\Src |
Where the code is generated to. We used 'C:\JDBCWizard.emo\Src'. |
| 4.2 - Enter package name |
com.orindasoft.demo.generated |
Should always end in
'generated'. |
| 4.3 - DAO Factory Class name |
DAOFactory |
Our web service classes extend
DAOFactory. You can change the name if you want. |
| 4.3 - Log Messages Using... |
Text Log |
For the purposes of this
tutorial we'll use Orinda's com.orindasoft.pub.TextLog
instead of the web server logging. |
| 4.3 - Get DB Connection Using... |
Hard coded connect string |
We're telling JDBCWizard that
we will create our own connection instead os using JNDI. |
| 4.3 - Log Name/Directory |
user.home |
This can be any valid directory
or the Java System Properties user.home or user.dir |
| 4.3 - Connection Name |
jdbc:oracle:thin:ORINDADEMO/ORINDADEMO@192.168.0.30:1521:LX1010 |
Because we're using a hard coded
connect string rather than JNDI we enter the string here. If we were
using JNDI we'd enter the JNDI name for the connection instead. You
will almost certainly have to change
this value to get your code to work. |
| 4.3 - Close Connections |
Selected |
We're telling JDBCWizard to
close the connection when it releases database resources. |
| 4.3 - Commit Connections |
Selected |
Tell JDBCWizard to call
'commit' at the end of each call. |
| 4.4 - Create Web Service Classes |
Selected |
The 'DAOFactoryServiceInterface'
and 'DAOFactoryServiceImpl' classes are only generated if this is
selected. |
| 4.4 - Interface Class Name |
DAOFactoryServiceInterface |
Axis's Java2WSDL works best when
you give it an Java Interface that only contains the public methods you
want turned into a Web Service. |
| 4.4 - Implementing Class Name |
DAOFactoryServiceImpl |
The name of the class that will
extend our DAOFactory class and implement the web service methods. |
| 4.4 - Number type used by service |
double |
By default generated code uses
java.math.BigDecimal to represent numbers. For convenience you can
change this to a friendlier Java datatype. |
| 4.4 - Always Release Connection |
Selected |
Tells JDBCWizard to get rid of
the database connection at the end of each Web Service call. This is
not efficient but makes demonstrations simpler. |
Having filled in your values recheck the value for 'Connection Name' and move on to the last step.
Press the 'Generate Code' button to generate your code. You can then exit JDBCWizard.


The next step is compiling the code. Before we can do this we have to add an Oracle JDBC driver and the OrindaSoft com.orindasoft.pub library JAR files to the project.

At this
point the code
should compile and be usable. To make sure of
this we'll write a small additional class to test that we can connect
to the database:
| File
C:\JDBCWizard.emo\Src\com\orindasoft\demo\WsTest.java |
|
When run one of two things will happen. If the code is working then you'll see something like this:
|
|
If you do get an error there is no point in continuing until you have resolved it.
Using either the 'jar' program or your IDE create a JAR file containing your generated code. In order for our JDBCWizard JAR file to be usable by Axis it will need two other JAR files:
Shutdown the Tomcat web server and copy all three of these files into Axis's 'lib' directory. The Axis file stricture should then look like this:

We now need to deploy our
application to Axis. Before continuing you
should have read the following Axis Documents:
| The Java2WSDL:
Building WSDL from Java section in the Apache Axis User Guide |
| The section on Java2WSDL
in the Apache Axis Reference Guide. |
In order to
create our
WSDL
file we need a CLASSPATH with the entire
contents of the axis\WEB-INF\lib directory on it, including
This can be done using a script or by creating a new project in your IDE and adding the libraries. Do NOT use the same Java project you generated the code in for this. We created a new project called 'orindademo_java2wsdl' and added all the libraries from axis\WEB-INF\lib:

| File C:\JDBCWizard.emo\Src\com\orindasoft\demo\WsRunJava2WSDL.java |
|
| File C:\OrindaTemp\orindademo.wsdl |
|
Having created our WSDL file we now use it to create deploy.wsdd and undeploy.wsdd, which are needed to tell Axis about our service. The program below was used to generate our WSDD files.
| File C:\JDBCWizard.emo\Src\com\orindasoft\demo\WsRunJava2WSDL.java |
|

deploy.wsdd contains the much of the same information that C:\OrindaTemp\orindademo.wsdl does, but in a different format.
undeploy.wsdd
is much
smaller because it doesn't have to define
how the service should work, only that it should be removed.
Also
visible will be a large
number of Java files. They are a
'default
server implementation' - files that have the right methods but don't
actually do anything. Because we have used JDBCWizard we already have
all the code we need and do not need them. Do not let these Java files
into your CLASSPATH and whatever you do don't create them in the same
project as your JDBCWizard generated code.
| File C:\JDBCWizard.emo\Src\com\orindasoft\demo\WsRunAdminClient.java |
|
When run this program should produce output like this:
|
The "Done Processing" message is a good sign but does not mean that the deployment succeeded.
The first step in testing our web service is to see if it shows up in Axis's list of services, which in our case is at the URL http://localhost:8080/axis/servlet/AxisServlet. If everything is working we'll see the following:
| http://localhost:8080/axis/servlet/AxisServlet |
And now... Some Services
|
We should now be able to write a client program to use our web service. 'WsCreateClient.java' is very similar to 'WsRunWsdl2Java', the main difference being that it uses the service URL instead of a WSDL file. We also generate the code to a new location - 'c:\\OrindaDemoClient'. This is because we'll create a third project in our IDE to test the Web Service end to end.
File
C:\JDBCWizard.emo\Src\com\orindasoft\demo\WsCreateClient.java |
|
When run for the first time this program should terminate without any messages from Apache Axis. If you want to run it again you'll need to delete the code it created to avoid a 'ORINDADEMOSoapBindingImpl.java already exists, WSDL2Java will not overwrite it.' message.
We should now be able to run an end-to-end test. Since we want to show that we really are using the web service and not logging into the database we'll create a third project in our IDE that doesn't have a JDBC driver or JDBCWizard libraries in its CLASSPATH. Note that we fix it so that the project is pointed at the code we just generated in C:\OrindaDemoClient.

We
then have to set up the libraries for
our test client project.
We
import all the Apache Axis libraries but do not import an Oracle JDBC
driver, the generated code or the OrindaSoft com.orindasoft.pub
libraries.

| File
C:\OrindaDemoClient\com\orindasoft\demo\AxisTestClient.java |
|
|
The program above demonstrates how JDBCWizard makes it easy to implement web services with Oracle.
Once you've got your first Axis Web Service to work you should consider the following:
Use JNDI for database Connections - JNDI is a far better way of managing database connections than hard coding a connect string like we did in our demo.
Use Log4J for logging - Log4J or java.util.logging
are both options for generated code. Using a built in logging protocol
will make integrating generated code much easier.
Allocate appropriate amounts of memory for your Web Server - The Java Virtual Machine defaults aren't big enough in most cases.
Make a list of PL/SQL stored procedures and SQL statements you want in your web service - Many existing PL/SQL procedures will probably be usable in a web service without modification. By examining existing application code you will be able to find the SQL statements that drive your application and make copies of them that are usable by JDBCWizard.