PHP is a top Web development language, and the Java™ programming language is popular for business application development. Thus, to utilize the strengths of each language on the AIX® Version 5.3 operating system, the PHP Java Bridge has been developed. The goal of this series is to get AIX 5.3 developers up to speed in integrating both PHP and Java technology in Web application development.
To demonstrate this, you will build a simple survey application that follows a typical development process, including:
- Developing the main Java application
- Exposing the Java application through servlets as a Java-based Web application
- Adding support for storing information within a database
- Exposing the original application as Web service and providing a PHP interface to the application
- Redeveloping the PHP interface using the dedicated PHP Java Bridge
The series is split into six parts:
- Part 1 looks at the application and sets up an environment ready for building Java applications and serving Java-based Web applications using Tomcat.
- Part 2 covers the main application code and the development of a simple Java Servlet to provide a Web interface to the information.
- Part 3 connects the core application to a DB2® database for the storage of the survey questions and responses.
- Part 4 converts the original application into one that can be accessed as a Web service, and it provides the base for the PHP interface.
- Part 5 builds the PHP interface to the Java application by using the PHP Java Bridge.
- Part 6 redevelops the application to make use of the PHP Java Bridge in place of the Web service interface.
Using PHP and Java technology together
One of the most common issues for an enterprise developing a new interface to their application is how to architect the solution. With the move to Web-enabled applications, the temptation is to develop a Web-based wrapper around an existing application that uses the existing language and framework.
This can cause problems for some environments, as the deployment situation for a Web application can be based on a completely different technology and, in many cases, the skills and advantages of a particular environment cannot always be utilized to the fullest extent.
The same problems can occur even when developing a new application—Web development experts are used to one environment, such as PHP, and your business application logic experts are experienced in Java technology. Sometimes you might just want to take advantage of the flexibility offered by the different environments. PHP allows for very rapid application prototyping of Web applications, and the freeform mix of HTML and embedded PHP commands makes it very easy to develop a Web interface.
Although the Java environment is fully capable of Web deployment using Java Server Pages (JSP) and native solutions, such as Struts for HTML object deployment, it is also more commonly used as the core application logic in part of a larger application. With the strong typing and standardization within the Java environment, it is often better suited to the complex business application development solutions.
The key is to use a solution that enables you to use both solutions for the different parts of your application—back-end logic and a front-end interface—using Java and PHP technology with an interface between the two for the exchange of information.
There is no convenient direct link between Java and PHP technology—they are two different technologies using completely different logic, binary, and deployment environments. However, one way that you could enable both systems to communicate with each other is to employ Service-Oriented Architectures (SOAs) and Web services to exchange information. In this example scenario, you would expose your Java application through a series of Web services. The PHP application would then act as a Web services client to communicate with the Java Web services interface.
The other alternative is to use the PHP Java Bridge, which provides a direct object interface that allows you to share Java and PHP code directly within the same application.
In this series of articles and tutorials, you'll be looking in detail at how to develop a Java application that is then extended by using a PHP interface to the underlying Java code.
Throughout the series, you'll build a simple survey system that provides a series of questions, collects the answers, and then provides statistical analysis on the answers.
The application logic for the survey is built within the Java code, using a base class for the survey. You'll also build a single base class (that holds the core data for a question) that you can expand to other classes to support the different response types (multiple choice, text entry, rating, and so forth). You can see the basic survey class structure in Figure 1.
Figure 1. Survey application core classes
To expose the application through a Web interface, you need to build a Java servlet that expands on the original question classes, supports the ability to output the question as HTML, and receives the response. The structure for that element can be seen in Figure 2.
Figure 2. Exposing the survey application as a Java-based Web service
Because you'll want to be able to store the result information, you need to build an interface to the DB2® database and an extension of the main Survey class so that the received responses can be written into a database.
To provide a PHP interface to the system, re-adapt the application to operate as a Web service from the Java end that you can then access from a PHP application to provide an alternative interface. The final stage is a redeployment of the application using the PHP Java Bridge to maximize the performance of the system.
To achieve the first two steps developing the core application and then deploying the application as a Java servlet, you need to install both the Java programming language and Apache Tomcat—a Java servlet deployment environment. Let's start by installing and setting up the Java programming language.
Installing the Java programming language
You need to install the Java Software Development Kit (SDK) Version 5 or later, and you need the development, not runtime, environment, as you will need to compile Java source code into the classes required for the core application object in the example application.
Java V1.4 SDK 32-bit is available on the AIX Version 5.3 distribution media, and
it is probably already installed on your system, as it is required for WebSM. You
can verify this by running lslpp -L Java14.sdk. A
64-bit Java 5 SDK is available on the IBM developerWorks site (see
Resources). In addition to being a more recent Java
release, 64-bit applications run more efficiently on 64-bit hardware with a 64-bit
kernel. To install:
- Download the Java5_64.sdk.tar.gz file to your system.
- Extract the SDK with
gunzip -c Java5_64.sdk.tar.gz | tar -xvf -. - As the root user, install the SDK using the command line:
installp -a -d Java5_64.sdk all.
Or through SMIT:
- Run smitt install.
- Select Install and Update Software.
- Select Install Software.
- Specify the full path to the file containing the image (for example, /usr/local/src/Java4_64.sdk).
- Click OK.
- Click OK and the SDK is installed.
Apache Tomcat provides a JSP deployment platform. You can use this to deploy Java applications using a Web interface or for supporting Web service application deployments. In this series, you'll be using Java technology as the Java services platform and, later, as a solution for Java and PHP cross-platform development.
Tomcat is probably the easiest component of the system to install and deploy. As a native Java application, once you have the Java application installed, installing and setting up Tomcat is very straightforward.
To install Tomcat:
- Download the latest Tomcat package (see Resources). As of this writing, V6.0.10 was the latest stable release of Apache Tomcat.
- Extract the Tomcat package using
tarandgunziporunzip:$ gunzip -c apache-tomcat-6.0.10.tar.gz|tar xvf -. - Move the extracted directory to the location where you want to install Tomcat,
but do not rename the directory that was created. For example:
$ mv apache-tomcat-6.0.10 /usr/local. - Create a symbolic link between the real directory and the name you want to
use. This makes it easier to upgrade to a later Tomcat version when you need to:
$ ln -s /usr/local/apache-tomcat-6.0.10 /usr/local/tomcat.
Because Tomcat is a Java application, there are no special install or build processes to follow. You should now be ready to install and start Tomcat.
Before you start Tomcat for the first time, you should double check the configuration of the Tomcat system to ensure that it matches your own environment. Before you examine the configuration, it is worth looking at the basic directory structure of a Tomcat installation:
- LICENSE
- NOTICE
- RELEASE-NOTES
- RUNNING.txt
- bin/
- conf/
- lib/
- logs/
- temp/
- webapps/
- work/
The key parts of the Tomcat installation are as follows:
- The bin directory contains the main scripts and applications that control and
run the Tomcat application. The directory holds shell scripts, native
Windows® applications, and Windows batch files. You should run
chmodon the shell scripts in this directory to ensure that you can start, stop, and control your Tomcat installation:$ chmod ugo+x bin/*.sh. - The conf directory contains the files that hold the configuration information for Tomcat. You rarely need to change the configuration once you have initially set up Tomcat, as most of the installation and deployment can be controlled directly through the Tomcat interface.
- The lib directory contains the libraries and Java code that actually constitute the Java system.
- The logs directory is automatically created by the Tomcat server when it is installed and contains the log files (including error logs).
- The temp directory is also automatically created by the Tomcat server when it is installed and contains any temporary files.
- The webapps directory is the where you install the components of your Web applications. You can install JAR files, WAR files, and the JSP files that make up your application. By default, Tomcat includes documentation, examples, and management applications for controlling your Tomcat installation in the webapps directory.
- The work directory contains working components of a running application, and it is automatically created by Tomcat while it is running.
Now let's examine the configuration of Tomcat, as you might need to update parts of the configuration to suit your environment.
There are a dizzying array of options within Tomcat to configure a wide variety of functionality and options. Typically for a standard installation, you do not need to worry about the majority of options.
A number of key elements might need to be configured. By default, Web servers generally operate on the TCP/IP port 80; to avoid conflicting with this, Tomcat runs on port 8080 but, on some servers, you might already have this configured for use by another application, such as a Web proxy.
You can change the default port that Tomcat listens to by editing the conf/server.xml file. You need to find the "Connector" block within the Catalina service -- it is usually in the top 50 lines of the file. You can see a sample in Listing 1 below.
Listing 1. The Connector block
<Service name="Catalina">
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL HTTP/1.1 Connector on port 8080
-->
<Connector port="8080" protocol="HTTP/1.1"
maxThreads="150" connectionTimeout="20000"
redirectPort="8443" />
|
Change the port attribute value to the port that you want to use. If necessary,
you might also want to adjust the redirectPort
attribute, which contains the port to be used for Secure Sockets Layer (SSL)
connections. If you do change this value, make sure you also change the port
specification for the SSL connection, as shown in Listing 2.
Listing 2. Changing the port specification
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the JSSE configuration, when using APR, the
connector should be using the OpenSSL style configuration
described in the APR documentation -->
<!--
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
-->
|
If you want to support the service on a specific host on a server with multiple network interfaces or addresses, then you must also alter the host name specification. This is set in two locations, first within the Engine tag and then within the specific Host tag, as shown in Listing 3.
Listing 3. Alter the host name specification
<Engine name="Catalina" defaultHost="localhost">
...
<!-- Define the default virtual host
Note: XML Schema validation will not work with Xerces 2.2.
-->
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
|
You must change the defaultHost and then the
corresponding name attribute.
The only other file within the configuration that you should examine is the conf/web.xml file. You do not need to edit this file yet, but it is a good idea to familiarize yourself with the content, as you must edit this file when setting up additional applications within the Tomcat server.
Once Tomcat has been installed and configured, you can start the Tomcat server. First, make sure that your JAVA_HOME environment variable is set to the right installation location for your Java environment. If you have installed Java5_64, then the installation is located in /usr/java5_64 (see Listing 4).
Listing 4. Java installation location
$ JAVA_HOME=/usr/java5_64
$ export JAVA_HOME
|
You might also want to explicitly add the Java execution path in your main PATH, as shown in Listing 5.
Listing 5. Add the Java application to your PATH
$ PATH=$JAVA_HOME/bin:$JAVA_HOME/rje/bin:$PATH
$ export PATH
|
Optionally, you can also set the path to the Tomcat installation in an environment variable to make it easier to locate (see Listing 6).
Listing 6. Set the Tomcat path
$ CATALINA_HOME=/usr/local/tomcat
$ export CATALINE_HOME
|
You should now be able to start Tomcat using the shell scripts provided. The startup script prints out the configuration information (see Listing 7).
Listing 7. Tomcat startup script
$ $CATALINA_HOME/bin/startup.sh
Using CATALINA_BASE: /Data/Incoming/apache-tomcat-6.0.10
Using CATALINA_HOME: /Data/Incoming/apache-tomcat-6.0.10
Using CATALINA_TMPDIR: /Data/Incoming/apache-tomcat-6.0.10/temp
Using JRE_HOME: /usr/java5_64
|
If any errors are reported, you might want to check the more detailed log in logs/catalina.out. A sample of the output is shown in Listing 8 below.
Listing 8. Catalina.out log
Mar 31, 2007 8:51:11 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The Apache Tomcat Native library which allows optimal performance in production
environments was not found on the java.library.path: /usr/local/lib:/u
sr/local/apr/lib:.:/usr/java5/extensions:/usr/java5/lib
Mar 31, 2007 8:51:13 AM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Mar 31, 2007 8:51:13 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 5262 ms
Mar 31, 2007 8:51:13 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Mar 31, 2007 8:51:13 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.10
Mar 31, 2007 8:51:23 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Mar 31, 2007 8:51:23 AM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Mar 31, 2007 8:51:23 AM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/34 config=null
Mar 31, 2007 8:51:23 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 10466 ms
|
That should contain more detailed information on what went wrong. The most common problem is a port conflict with an existing service or a missing Java installation.
An easier way to test your Tomcat installation is to visit the Tomcat server page
once it has been started. If you have not changed the port number and you have a
browser installed on your server, then you can visit with that browser:
http://localhost:8080/.
If the Tomcat server is on another machine or you have changed the port number,
then substitute the localhost and 8080 values in the above example. For example:
http://192.168.0.170:8080/.
You should get a window similar to the one shown in Figure 3.
Figure 3. A running Tomcat installation
In this article, you've taken a brief look at the issues surrounding the development and deployment reasons for using PHP and Java technology on AIX and at some of the solutions available for integrating the two systems. You then looked at a basic application with a Java back end and classes to support different operations that you extend through a Web interface using PHP. In the next part of the series, you'll develop the core application logic using Java technology.
Learn
- "Develop with Java and PHP technology on AIX Version 5.3":
Check out other parts in this series.
- "Run
PHP applications in Apache Geronimo"
(developerWorks, February 2006): This tutorial provides basic information on
developing using PHP and Java technology.
-
PHP Java Bridge: For more
information on PHP Java Bridge, be sure to check out sourceforge.net.
-
Popular content:
See what AIX and UNIX content your peers find interesting.
- Check out other articles and tutorials written
by Martin Brown:
- Check out other articles and tutorials written
by Doug Monroe:
-
AIX and
UNIX®
:
The AIX and UNIX developerWorks zone provides a wealth of information relating to
all aspects of AIX systems administration and expanding your UNIX skills.
-
New to AIX and UNIX?:
Visit the New to AIX and UNIX page to learn more about AIX and UNIX.
-
AIX 5L™ Wiki:
A collaborative environment for technical information related to AIX.
- Search the AIX and UNIX library by topic:
- System administration
- Application development
- Performance
- Porting
- Security
- Tips
- Tools and utilities
- Java technology
- Linux®
- Open source
-
Safari bookstore:
Visit this e-reference library to find specific technical resources.
-
developerWorks technical events and webcasts:
Stay current with developerWorks technical events and webcasts.
-
Podcasts: Tune in and
catch up with IBM technical experts.
Get products and technologies
-
IBM trial software:
Build your next development project with software for download directly from
developerWorks.
-
Tomcat: Download the latest package.
-
Java 5
64-bit SDK:
You need to register to download this package, but registration is free.
-
Mozilla: The Mozilla Web
browser for AIX can be downloaded from IBM.
Discuss
- Participate in the
developerWorks blogs
and get involved in the developerWorks community.
- Participate in the AIX and UNIX forums:
- AIX 5L -- technical forum
- AIX for Developers Forum
- Cluster Systems Management
- IBM Support Assistant
- Performance Tools -- technical
- Virtualization -- technical
- More AIX and UNIX forums
Doug Monroe is a UNIX System Administration consultant and instructor with DMA Inc. He holds a bachelor's degree in computer science from Oregon State University, and he has been supporting various flavors of UNIX since 1984. You can reach him at monroe@sqnt.com.
Martin Brown has been a professional writer for over eight years. He is the author of numerous books and articles across a range of topics. His expertise spans myriad development languages and platforms -- Perl, Python, Java, JavaScript, Basic, Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows, Solaris, Linux, BeOS, Mac OS/X and more -- as well as Web programming, systems management, and integration. Martin is a regular contributor to ServerWatch.com, LinuxToday.com, and IBM developerWorks, and a regular blogger at Computerworld, The Apple Blog and other sites, as well as a Subject Matter Expert (SME) for Microsoft. He can be contacted through his Web site at http://www.mcslp.com.





