![[ZOIS]](../pics/little.zois.gif){kind=small}
Home Page *
Contact ZOIS *
Technical Notes
ZOIS Technical Note TN-2001-10-15.
This TN is intended for persons working with Java 2 Enterprise Edition
(J2EE) products and methodologies on Linux and similar platforms. UNIX
systems and Java programming skills are assumed. Written by Martin
Sullivan[1], ZOIS Limited, Cockermouth.
Abstract
The current (as in late 2001) ZOIS J2EE demonstrator
uses Apache 1.3 to Tomcat 3.2 to JBoss 2.2 to PostgreSQL 7.0 on Red Hat
6.2 Linux. This is how these tools were installed and configured.
Introduction
Large OLTP systems, although frequently referred to as 3-tier, can in-fact contain a multiple of layers. Typically, a large CICS[2] system will contain terminals which will connect to a CICS Region dedicated to handling them which will connect to a CICS Region handling business logic which will in turn connect to a database.
With the advent of J2EE a similar architecture is evolving, probably driven by the same underlying goals and needs. This sees terminals connected to a layer handling presentation and consolidation issues connecting with a layer handling business logic which in turn connects to a database.
It was decided to build a best-of-breed demonstration system based on the most popular Open-Source (defined in its loosest sense) tools. Therefore the following choices were made:
The initial goal was to complete a system demonstrating the simplest
possible minimum-code example. It was there for decided to emulate the
Tuxedo Simpapp[3] example, which sends a String of
characters through to business logic and has it uppercase them. This
example would, to demonstrate database connectivity, accomplished
uppercasing in SQL using the database engine. The J2EE Simpapp is
described in another TN[4].
Materials and Platform
The J2EE demonstration will run on the Red Hat[5]
distribution of Linux (version 6.2, kernel 2.2.14). It will
run on conventional Intel based PCs and Laptops, to allow demonstrations
at remote sites. The minimum for this works seems to be a 200 MHz CPU and
64 Mbytes of main memory. A generous amount of disk space is required
too and the /opt directory was used as the installation target for all
non-Red Hat packages. The Java used was IBM's 1.3 (IBMJava2-13) for Linux.
Method
The Apache used is installed with the Red Hat 6.2 Linux distribution and is version 1.3.12. The configuration was adjusted however to change one or two things, secondary to the demonstration platform, such as Proxies and Canonical naming. These changes have been documented in a TN detailing an upgrade to Apache 1.3.24[6].
Tomcat is Web Container, something that acts as an executable environment for Java Server Pages (JSP). Java Server Pages are executable Java program elements that are embedded into HTML pages. These are stripped out and compiled up on the fly as `Serverlets', Java programs linked to HTML pages, allowing dynamic content in HTML pages. Tomcat is a `pure'-Java example of such a container. It is, with the exception of one or two scripts, entirely written in Java. As such a binary distribution for version 3.2.3 was downloaded and installed. There were one or two configuration issues to allow connection between it and Apache and it and JBoss.
The connection between Tomcat and Apache is managed by an Apache Dynamic Share Object (DSO). There are two of these, Jserv and Jk. Jserv is actually a Web Container in its own right. It is, however, now deprecated in favour of Tomcat and is used now only for linkage between Tomcat and Apache. The Jk module is somewhat more recent and is purely concerned with connecting Tomcat and Apache. A version of Jserv is distributed with Red Hat, but it was decided to implement Jk. Consequently the Jk DSO module (mod_jk.so) was downloaded as a binary for Linux on Intel from the Tomcat web-site and dropped into the libexec directory found under the Apache root (/etc/httpd on Red Hat 6.2). The following line was then added to the Apache configuration file (conf/httpd.conf)
Include /opt/tomcat/conf/mod_jk.conf-auto |
The Tomcat conf/mod_jk.conf-auto file is then modified, usually by a cut-paste-modify-to-taste mechanism to allow a subdirectory in the Tomcat webapps directory to contain deployed JSPs.
The connection between Tomcat and JBoss is that of an EJB Client connecting to an EJB Server. Tomcat and JBoss can thus be separate and a number of Tomcat installations can feed into a number of JBoss installations. Using this mechanism, and as much statelessness as possible, the demonstrator can scale within the limitations of hardware and the database manager. For the purposes of portability, however, both Tomcat and JBoss reside on the same machine in the demonstrator.
EJB Clients need to find a number of Java archive (`jar') files containing classes to allow them to function. They need to find the Java Class files which define the interface between Client and Server too. This is largely accomplished by using the CLASSPATH environment variable, although the same effect could be placing the appropriate `jar' files into a directory that is searched by default (for example lib). The CLASSPATH mechanism was used in this instance and is actually used by both Tomcat and JBoss:
CLASSPATH=${CLASSPATH}:${EJB_ROOT} #Simpapp lives here
CLASSPATH=${CLASSPATH}:${JBOSS_HOME}/lib/ext/ejb2.0.jar
CLASSPATH=${CLASSPATH}:${JBOSS_HOME}/lib/ext/jboss.jar
CLASSPATH=${CLASSPATH}:${JBOSS_HOME}/lib/ext/jnpserver.jar #jni
CLASSPATH=${CLASSPATH}:${JBOSS_HOME}/lib/ext/jta-spec1_0_1.jar #jta
CLASSPATH=${CLASSPATH}:${JBOSS_HOME}/lib/ext/jms.jar #jms
CLASSPATH=${CLASSPATH}:${JBOSS_HOME}/lib/ext/jbossmq.jar #jms
CLASSPATH=${CLASSPATH}:${JBOSS_HOME}/lib/jdbc2_0-stdext.jar #jdbc
CLASSPATH=${CLASSPATH}:${JBOSS_HOME}/client/jbosssx-client.jar
|
The Tomcat based EJB Clients also need Java Naming and Directory Interface (JNDI) information to allow them to connect to their Servers. This is accomplished by having a properties file (jndi.properties) somewhere on CLASSPATH. The contents of this file specify a local address (localhost) for the JNDI service, it is on the same host as Tomcat (and JBoss):
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.provider.url=localhost java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces |
CLASSPATH=${CLASSPATH}:${EJB_ROOT} #Simpapp lives here
JBoss is an Enterprise Java Beans (EJB) Container, an execution environment for EJB. As with Tomcat this is a `pure'-Java based system in that with the exception of the odd shell script it is entirely written in Java. JBoss is currently attracting a lot of attention since it not only is free but also has a an attractive deployment mechanism whereby no `extra' XML descriptions need to be written and once archived into a `jar' file, the bean can be deployed by simply placing it in deploy directory. Contrast this with more commercial rivals which need extra XML files written and the `jar' file, once assembled, `compiled' with a further program prior to deploying with a specialized tool.
Since JBoss is a Java based system the binary download was obtained from the JBoss web-site[7]. This was installed without problem according to the accompanying instructions. Version 2.2.1 was used.
Connection to Tomcat would be through client-server connections, where Tomcat was informed of the appropriate interface class and the location of the JBoss Java Naming and Directory Interface (JNDI) provider through a mixture of CLASSPATH entries and properties file. This is discussed in the above Tomcat section.
Connection to the PostgreSQL database would be through Java Data Base Connectivity (JDBC). The basics of this are provided by a Java Archive (`jar' file) distributed with the PostgreSQL Database Management Software. It makes a TCP/IP based connection with the PostgreSQL backend and passes SQL and results too and fro. To allow scaling JBoss pools connections and employs a connection manager to distribute them. Thus an EJB can make and break a connection to a database (normally a costly operation) with out actually doing so. The connection is from a pool of already open connections and is returned to it once it is no longer needed.
JBoss needed configuration therefore to use PostgreSQL. Firstly the PostgreSQL JDBC `jar' file, postgresql.jar, is placed in JBoss's system library directory, lib/ext. It is then declared to JBoss as JDBC Provider by adding the correct Java Class name (org.postgresql.Driver) to the JdbcProvider entry in the JBoss configuration file. This configuration file, called jboss.jcml, is found in conf/default under the JBoss home directory.
<mbean code="org.jboss.jdbc.JdbcProvider" name="DefaultDomain:service=JdbcProvider"> <attribute name="Drivers">org.postgresql.Driver,org.hsql.jdbcDriver,org.enhydra.instantdb.jdbc.idbDriver</attribute> </mbean> |
This file then requires the following entirely new entry to define a PostgreSQL Data Source known as "PostgresDS".
<mbean code="org.jboss.jdbc.XADataSourceLoader" name="DefaultDomain:service=XADataSource,name=PostgresDS"> <attribute name="PoolName">PostgresDS</attribute> <attribute name="DataSourceClass">org.opentools.minerva.jdbc.xa.wrapper.XADataSourceImpl</attribute> <attribute name="Properties"></attribute> <attribute name="URL">jdbc:postgresql:sullivan?user=sullivan?password=-not-required-</attribute> </mbean> |
In the above example the database sullivan is used by a
user sullivan without a password. This is passed to
PostgreSQL via the URL attribute, avoiding the need for user and
password attributes.
This Data Source can be later used in an EJB using the following Java code fragments which use JNDI to find and then obtain a connection from it ...
Context ctx = new InitialContext ();
ds = (DataSource) ctx.lookup ("java:/PostgresDS");
|
Connection conn = ds.getConnection (); PreparedStatement sql = conn.prepareStatement (SQL); |
Red Hat 6.2 Linux provides PostgreSQL 6.5. Although a JDBC connector has been developed for this version it was decided that the demonstrator should use PostgreSQL 7.0.2 which has a JDBC connector in the distribution.
PostgreSQL was therefore obtained as a source distribution from
the PostgreSQL web-site[9] and compiled up. No issues
were noted and the /etc/rc start-up scripts were adjusted to
use the new binaries and pg_ctl to start, stop and query status. The
distribution was deployed in the /usr/local/pgsql directory. The createdb
and createuser commands were used to create a database
sullivan for user sullivan which JDBC could
be used to connect to.
Conclusion
A framework of connections that need to be made between Apache, Tomcat,
JBoss and PostgreSQL has been built and demonstrated. It is actively
used in J2EE activities and to further explore aspects of Java based OLTP.
References
$Date: 2003/01/09 16:56:15 $