Recently in http://www.theserverside.com/
there is an ad from DataDirect technologies that says “What You Don’t
Know about JDBC CAN Hurt You”. It seems this ad is not
just hype.

Currently I am developing an end of day/end of month/batch
program for a bank. I usually use 4 database for testing purpose:
DB2, McKoi, MySQL dan MS SQL Server.

After a long time developing and testing using 4
database finally I change my habit and only using DB2 only
sometimes test in other database. Why? Because DB2 is the
fastest on insert and update. MySQL and SQL Server is fast enough
for insert and update but not as fast as DB2.

Few days ago I read announcement in JavaLobby about
a new release of jTDS driver for MS SQL Server and
Sybase. In the announcement they say that this driver
is faster than standard driver from Microsoft.
In the beginning I am sceptical. Can an Open Source driver
beats Commercial driver. Today I test jTDS driver.
It turns out the announcement is true. jTDS JDBC driver is
faster than Microsoft driver. It is so fast that
it beats DB2 for insert and update. And not just fast
it also succesfully run all my unit test which
means the behaviour of the driver is compliant
with JDBC specification.

We can see from this thing that the quality of
JDBC driver can influence application speed. Even though
the speed difference is only 15-25% but if our
application is run for hours like batch process
then 15-25% means time difference between half hour
to several hours.

This is really interesting times. The quality of some Open Source
software (some not all) can beat the quality of Commercial
software. Another fun thing for me is the compilation
of this driver from source is very easy

But the most important thing is in the README of this
driver the developer explain honestly which features are stable
and which features are not stable.
In the future Microsoft may release a faster driver
than jTDS however they may not be as honest as
jTDS developers. 🙂


Make Java Simpler

Creating scalable, complex and secure business applications for enterprise in Java is not easy. That’s why Sun creates J2EE SDK (Java 2 Enterprise Edition Software Development Kit). J2EE basically designed to create scalable, complex and secure business applications that can be deployed using 2 UI: Web and GUI. To achieve this Sun create JSP, Servlet, JAAS, JNDI, JTA, Java Mail and EJB specifications.

I believe Sun reached its objective because you can create scalable, complex and secure business applications using Java software that implements these specifications. However Sun do not consider that for many software developer some of this specifications is too complex and its learning curve is to steep. Sun needs to embrace not only J2EE architecture but also simpler architecture that can achieve almost the same objective but simpler and easier to learn. In essence Sun needs to make Java simpler.

After many hours of research I have found Java software that we can use to make scalable, complex and secure business applications. These Java software are easier to learn and simpler to use. They are: Velocity, XML-RPC and iBatis Database Layer. If we combine this software with J2EE then we will able to replace JSP with Velocity and EJB with XML-RPC and iBatis Database Layer.

Using Velocity it will be easier to learn how to create web application. The development process will also be simpler. JSP is a technology to translate JSP pages into Servlet transparently behind the scenes. This looks good until you reach its fundamental limitation: JSP is hard to debug.

Servlet are the foundation technology of creating web application using Java. This technology basically is a replacement of CGI (Computer Gateway Interface) technology. CGI is the first generation technology used to create web applications. A web application created using CGI technology works like this: web server receives request from web browser. If the request is not a request for static HTML pages but a request to a CGI executable then the request is passed to an executable by sending a standard output stream. The executable read the I/O stream from standard input. The executable processes the data and generates an output in the form of HTML pages. These HTML pages are sent back to web server by sending a standard output. The web server then forwards the HTML pages to web browser.

However CGI technology has one big limitation: it takes a lot of CPU and I/O capacity to load an executable repeatedly and communicate with it using only standard I/O stream. To eliminate this limitation Java programmers develop Servlet technology. Servlet is a Java object that lives within a Java web server. When a Java web server receives a request for a servlet it will call the object and pass the request from the browser. The call and the passing of request take place within one single instance of Java Virtual Machine. Therefore it doesn’t consume a lot CPU and I/O capacity and solves the big limitation of CGI technology.

However Servlet technology also has big limitation. It is tedious to create HTML pages using Java codes. You can’t use standard web design software that you can use to create static HTML pages. To solve this limitation Sun built JSP upon the foundation of Servlet technology. Basically when a Java programmer creates a JSP page he mixed HTML and Java codes. JSP technology takes this mixture and produces a servlet, compiles the servlet and sent the output of the servlet to web browser. Unfortunately this solution creates several problems: low maintainability and hard debugging.

Low maintainability of JSP happens because a novice web application developer is shielded from the concept of servlet. If you use servlet you has create HTML tediously using codes. Because it’s tedious you will try to reduce coding by packaging HTML parts in Java objects. Because JSP is so easy to create a novice web application developer will reuse their logic by copy and paste methods. In the end maintaining a web application developed by a novice web application developer will become a nightmare. Of course Sun try to rectify this by advocating implementing logic in JavaBeans and use of JSP tag library.

JSP is hard to debug because when your application has error servlet container can only point the line where the error exist in the servlets produced by JSP compiler and can’t point the line where the error exist in the JSP pages. Of course to make debugging easier you can implement a large part of your applications as JavaBeans objects and call them from JSP. However I believe solution offered by Velocity is better.

Velocity is a template engine technology. You create HTML pages using standard WYSIWYG web design tools like Macromedia Dreamweaver, Microsoft FrontPage, Adobe GoLive, etc. The developer creates business logic in Java class. In servlet you call Velocity engine to merge your HTML pages with Java objects. You can use Velocity template language in your HTML pages to implement display logic. Velocity template language is very simple. This is its strength. Because you can’t implement complex logic in Velocity templates then you are forced to implement complex logic only in Java class. When your application has error in the HTML template Velocity can pinpoint exactly the line where the error occurs. When your application has error in your Java class then stack trace from servlet container will pinpoint exactly the line where the error occurs.

In essence Velocity force you to change your work habit so creating an easy to maintain and debug web application will become natural to you.You can download Velocity from http://jakarta.apache.org/velocity/.

EJB is a good technology however the problems EJB designed to solve are not faced 80% of business application developer. Usually business application developer needs distributed computing technology only to solve 2 problems: scalability and applications integration.

These 2 problems can be solved much more easily by XML-RPC technology. XML-RPC is a distributed computing technology. You call methods in remote applications by sending XML text message over HTTP. You also receive the results of your method call in the form of XML text message. You can also call methods in remote applications asynchronously. In essence XML-RPC is using an RPC (Remote Procedure Call) paradigm. However XML-RPC is not an implementation of DCE (Distributed Computing Environment) RPC. DCE RPC (Microsoft also implement a variant of this RPC technology in Windows) is also distributed computing technology. However DCE RPC is using binary format data send over network protocol. DCE RPC can use many network protocols like NetBIOS, IPX, TCP/IP, etc. DCE RPC is a high performance distributed computing technology however developing an application using DCE RPC is not easy.

Because XML-RPC is basically a web application (XML over HTTP is basically the same as HTML over HTTP) you can scale it by using web application scaling techniques. Using hardware load balancer and hardware cache for web server you can scale your XML-RPC application easily. Techniques to scale web application are well-known and matured so I will not discuss it further.

XML-RPC specification is very simple. You can download XML-RPC specification from
http://www.xmlrpc.com/. The simplicity of the specification makes implementing XML-RPC server and client software very easy. Because of this many programming languages has free XML-RPC server and client implementation.

You can integrate an XML-RPC application easily to other XML-RPC application. To call a method in other remote XML-RPC application you only have to know the URL, the handler name and the method name. To implement a method that can be called using XML-RPC in Java you only have to specify the object and the handler name then mapped your servlet to an URL. Methods in your object will be discovered automatically by XML-RPC server using reflection. The only limitation you have to obey is your object must only accept certain data types as parameter and return results as certain data types. You can download XML-RPC for Java from http://xml.apache.org/xmlrpc/.

It is common for business application to required database portability feature. To address this Sun creates Entity Beans and JDO specification. Although you can have database portability using Entity Beans and JDO technology however implementing Entity Beans and JDO is much more difficult than implementing iBatis Database Layer. By using iBatis SQL Map you can put your SQL statement out of your code. Using iBatis SQL Map you put your SQL statements in XML configuration files. To run the SQL you just have to specify the name of the SQL Map and parameters of the SQL statement. Executing SQL Map API will execute the SQL statement and map database result set into Collections object and JavaBeans.

Database connection pooling and distributed caching is implemented in iBatis. These techniques make iBatis SQL Map very scalable technology similar to Entity Beans and JDO. You can download iBatis Database Layer from http://www.ibatis.com/.

To demonstrate Velocity, XML-RPC and iBatis Database Layer together in action I have created a sample application. You can download it at http://www.sfranklyn.com/inventory.zip.
The file size is 873 Kb.

To install this application you need to have the following software installed:

  • 1. Java 2 Standard Edition SDK version 1.4.x.
  • 2. Ant version 1.5.x or later. You need this to create database tables.
  • 3. XDoclet version 1.2 beta 3 or later. This is needed for compilation of the
    sample application. If you do not need to compile it then you do not need

  • 4. XJavaDoc version 1.0. This is needed for compilation of the sample application.
    If you do not need to compile it then you do not need it.

  • 5. JDBC driver of your relational database. Currently the sample application
    can be run using 6 databases: McKoi SQL, Microsoft SQL Server, MySQL, PostgreSQL,
    Oracle and IBM DB2.

  • 6. Tomcat version 5.0.x or later.
  • 7. A relational database supported by the sample application: McKoi SQL, Microsoft
    SQL Server, MySQL, PostgreSQL, Oracle or IBM DB2.

These are the installation steps:

  • 1. Download the sample application and unpack it into a directory. We will
    call this <APPDIR>.

  • 2. Install a relational database. Create a database named "inventory".
    Create user named "inventory". Set user password as "inventory"
    and grant table creation right to user.

  • 3. Copy JDBC driver of your relational database to <TOMCAT_HOME>\common\lib

  • 4. Create database tables. Open directory <APPDIR>\WEB-INF\database.
    If you are on Windows just run one of the batch file according to your relational
    database. To run the batch file successfully please adjust build.xml file
    to point to your <TOMCAT_HOME>\common\lib directory. If you are on Linux
    or UNIX you can create database tables by calling ant directly. Just run "ant

  • 5. Install application context in Tomcat 5. Open directory <APPDIR>\WEB-INF\conf\<database>
    and copy inventory.xml into <TOMCAT_HOME>\conf\Catalina\localhost directory.
    Modify inventory.xml file to point to your <APPDIR> directory.

  • 6. Open <APPDIR>\WEB-INF\classes directory and modify Driver.properties
    file. Change the content of this file with one of <database>.properties
    file according to your database.

Now you are ready to run the sample application. Run Tomcat 5 by running startup.bat file in <TOMCAT_HOME>\bin directory. Open your browser and open http://localhost:8080/inventory/ address.

I want this simple architecture to be adopted by as many Java developers as possible therefore I grant public domain license of the sample application. If many Java developers adopt this simple architecture I believe success rate of Java developers will be increased. Of course if you need more features than this architecture can offer there are still EJB, SOAP, JMS and the whole bunch of J2EE specifications and implementations you can use. I wish success and God blessing to all Java developers out there.