Shared hosting can run a Java application

Markus Eisele

Since corporate processes have been increasingly relocating to the web, there has been a growing need to combine established Internet technologies such as PHP with Java enterprise applications. Standard products for linking are still in short supply, but some approaches are promising.

Anyone who wants to connect their Java backend with dynamic websites, often created with the popular PHP, cannot yet make use of a rich selection of suitable technology or even numerous mature products. Nevertheless, it is worthwhile to examine some of the existing information more closely.

An execution environment for the PHP scripting language runs as a separate service or process, depending on the operating system. Apart from the interfaces to web servers such as Apache's HTTPD or Microsoft's IIS, PHP does not offer any standardized object interfaces. In principle, the latter also applies to a Java Virtual Machine (JVM). If you want to get PHP and Java programs to talk to each other, you need suitable intermediate pieces. They dock on the rudimentary interfaces of the respective processes, pack and unpack transferred objects that handle communication (invisible to the developer) across process boundaries, and provide programming interfaces (APIs).

When looking for such adapters, you will soon come across the PHP Java Extensions. These extensions use PHP's object overloading to access Java classes. If a PHP program calls a Java method on an object, a JVM is first generated via the Java Native Interface (JNI). The return value can be displayed in the PHP pages. The first attempts at walking with this solution are arduous. The developer has to configure and install a number of things, and the combination with JNI does not promise particularly stable systems. This construction quickly kneels under load. In the worst case, every request starts a complete JVM. A server with large main memory should be available for such experiments. Instance pooling or other recycling does not take place here.

Embedded Experiments

Embedded Experiments

Something similar can be reported about the PHP servlet SAPI. However, it does not embed Java in PHP, but PHP in Java: A Java web container (such as Tomcat) has a PHP instance built into it via a servlet. Although the SAPI module is based on the mechanisms of the PHP Java Extensions, it is more stable and more efficient. Mainly because the servlet engine takes care of the pooling and recycling of the JVMs and the PHP kernel is only loaded when required. There are pro and contra voices for both variants in relevant forums and articles. It feels like the problem reports predominate. For this reason the PHP extensions for PHP 5 are marked as experimental. Both approaches are not yet suitable for productive environments.

The two proposals may seem strange to the Java developer, as he knows that the Java Specification Request (JSR) 223 was implemented with Java 6. This JSR describes an API that shows a way to integrate scripting languages ​​into the Java world. The JSR defines a so-called scripting engine for each language. Although the search in Sun's scripting project does not reveal a corresponding engine, two products can be found elsewhere that implement the Scripting API for PHP: The PHP / Java Bridge on Sourceforge and the native Java implementation of PHP called Quercus by Caucho. The API reduces the use of PHP scripts in Java to the quatrain:

ScriptEngineManager m = new ScriptEngineManager ();
ScriptEngine phpEngine = m.getEngineByExtension ("php");
ScriptContext context = phpEngine.getContext ();
Object php2javaResult = phpEngine.eval ("<" php echo \ "hello world \";
?> ", context);

This allows Java developers to easily transfer return values ​​from any PHP methods and classes into their programs. However, the way in the other direction remains closed for the time being. The scripting engine alone is not able to execute PHP files and classes in a Java application server. Quercus and the PHP / Java Bridge provide the necessary trimmings, more on that later.

One of the native options is PHP-Java interaction using web services. However, this is not about close interlinking of the two worlds, but only about loose cooperation. Still, this option has its charm. Java EE can handle web services without any problems, but you have to upgrade the PHP side. A number of frameworks can be considered for this, for example NuSOAP, a web services toolkit for PHP. However, the developers have to create interfaces on both sides for this path and agree on cooperation. The gain is a stable solution that affects both sides as little as possible. However, you have to cope with two separate infrastructures here.

Open in all directions

Open in all directions

The integration efforts presented below go deeper. The JSR 223 brings PHP closer to the Java developer, but his PHP colleagues remain without any noteworthy support. Various bridges want to remedy this shortcoming. There is a commercial alternative to the PHP / Java Bridge from Zend, the "PHP Company". Both products are able to access Plain Old Java Objects (POJOs) as well as other Java and Java EE components (EJBs, Connections, JMS etc.) from PHP. The PHP / Java Bridge offers two access options: A native Java bridge written in PHP and a PHP extension module implemented in C. The first way is easy to take, you just have to copy the relevant PHP classes to the web server. The following code snippet provides access to Java classes:

? php require_once ("java / Java.php");
$ string = new Java ("java.lang.String", "HelloWorld");
echo $ string;

This variant does not require any native code (or) to run. Big drawback: In contrast to the module written in C, it runs around ten times slower. Configuring the C module is difficult for this. Besides that, the developer has to copy a special one to the PHP extension folder () and register it in (). On Linux this all works without Java installed; Windows, on the other hand, requires a Java Development Kit (JDK). For example, the ready-to-use module could execute the following code:

$ system = new Java ('java.lang.System');
echo 'Java version ='. $ system-> getProperty ('java.version');

It is interesting that the PHP / Java Bridge works without JNI. In addition to the two modules described and the scripting engine, there is also a mono .Net bridge. Detailed information can be found on the project website.

Zend offers the Java Integration Bridge as part of its PHP platform. Unfortunately, the company website doesn't reveal too much that is worth knowing. Only the user guide reveals the architecture of the product. The Java Middleware Module follows the PHP standard. Access looks the same as with the PHP / Java Bridge. However, some additional programs help here. A component is installed on both the PHP and the Java side to handle the packing and unpacking of the transferred objects.

Braked solution

Good solution, a bit slowed down

To ensure the reuse of Java instances and better handling (pooling, threading, etc.), you don't just start any JVM and configure PHP to access it, but rather activate a special service that manages the Java instances. This service can be used to set both the port and the maximum number of available processes. Communication with the Java EE application server takes place via Remote Method Invocation (RMI). Disadvantage: A PHP program can only access objects that have a remote interface. In terms of performance, this way does not benefit from the optimizations anchored in the Java specification, the EJB local interfaces. According to its own information, Zend is currently working on this construction site. It should also be mentioned that the company launched the JSR 223 together with Sun, but has not yet presented an official PHP engine for Java.

Those who cannot cope with the options described so far have one last option. In addition to the official PHP distribution, there is the Quercus version, which is licensed under the GPL and written in Java. As already mentioned above, this marvel comes from the company Caucho, manufacturer of the application server Resin, which also contains Quercus. Quercus' scripting engine is the same as the PHP / Java Bridge. The developer benefits from the additional functions that the package provides. This includes a servlet wrapper for PHP calls and the complete management of the PHP instance within the web container. Quercus can be downloaded as a web application (). After unpacking, the programmer has to move this file into the application directory of any web container and a reasonably up-to-date PHP 5.2 under Java is available to him. This makes it very easy to offer PHP functions to existing Java applications. He still has to copy two Java libraries into the and register the PHP servlet in the:


Unfortunately, not everything is as simple as it seems at first. A lot of PHP modules are already available for Quercus (including APC, iconv, GD, gettext, JSON, MySQL, Oracle, PDF and Postgres) but the offer does not yet cover the full range. Nevertheless, many well-known PHP applications can run under Quercus, such as DokuWiki, Drupal, Gallery2, Joomla, Mambo, Mantis, MediaWiki, Phorum, phpBB, phpMyAdmin, PHP-Nuke, Wordpress and XOOPS. Unfortunately, the free version of the tool disappoints with one major disadvantage: database access can only be carried out via the Java Naming and Directory Interface (JNDI). Normal PHP access only works in the licensed professional version of the Application Server.

// PHP DB access
// mysql_connect ($ host, $ username, $ password, $ dbname);
// JNDI access mysql_connect ("java: comp / env / jdbc / myDatabaseName");

Another delicacy that only professional licensees can enjoy: Quercus can not only interpret PHP sources at runtime, but can also precompile them if desired. In productive environments, there is certainly a performance gain here.

It is not possible to give a general recommendation for the right path, the requirements are too different. If you want to occasionally use some Java functions in PHP websites, you have to build a different architecture than someone who wants to add PHP parts to a Java web application. The most frequently requested scenario is probably the Java backend outlined at the beginning with business data in conjunction with an agile and modern PHP web interface. For companies that want something like this, a product can score with professional support - and here there is only Zend's Java Integration Bridge. If you don't need commercial support, you can try the PHP / Java Bridge project on Sourceforge. The easiest way to communicate is via web services (XMLRPC / SOAP). As a rule, you don't even need an additional architecture component for this, but you don't get an integrated solution either.

Markus Eisele
works in the field of software technology in the Center of Competence IT Architecture at MSG Systems AG.

Online sources

Online sources

PHP basics

PHP: Technical Basics

In order to be able to execute a PHP file as part of a web application, you need a system that can handle the instructions contained in the source code. Conventional web servers are not able to do this. However, they offer an interface (for example ISAPI or CGI) for the interpreter. As soon as a web server is supposed to deliver a registered file (for example), a server daemon or service (for example Apache or IIS) transfers it to the interpreter. However, the whole thing is not performing well. This is why this approach has been gradually replaced by Apache modules over the years. Today, Apache's web server offers various components for working with scripting languages. is responsible for integrating the PHP interpreter.

Java EE & Technology

Java EE and the technology

The Java EE specification provides a generally accepted framework in which distributed, multi-layer applications can be developed from modular components. In order to be able to execute and operate a Java EE application, you need an application server that provides execution environments for the components. The application server usually contains a web server that delivers the generated HTML to the browser. Only a part of the Java EE, namely the Java Server Pages (JSP), can be compared with PHP pages: Both are HTML pages enriched with code. In contrast to the PHP pages, JSPs are converted to servlets when they are run for the first time. A servlet is a programmed or generated Java class that can be executed in a Java EE web container.