Options for using PHP with WebSphere

I’m often consulted about adding PHP support to an IBM environment. Methods for connecting PHP to DB2, Informix and Cloudscape databases are covered pretty well, but it seems there’s a lot of understandable confusion about how to integrate PHP with WebSphere.

Just as you can communicate with DB2 from your PHP applications via three distinct interfaces – Unified ODBC, ibm_db2, and PDO – there are several approaches to adding PHP support to WebSphere Application Server, each with benefits and drawbacks.

As a disclaimer, I don’t claim to represent IBM or provide IBM’s viewpoints on this, but I’m offering this list as a general overview about what options are available as IBM continues to encourage the use of PHP in enterprise environments.

  • Build PHP as an Apache module and connect to WAS via the Web server plugin
    Essentially, any application server which uses an HTTP server (like Apache) on the front end can be configured as-is to support PHP, and has likely had this capability for years.

    When used in this configuration, it is only the HTTP server that needs to be configured to recognize patterns in the URL and to delegate requests accordingly. WAS and PHP know nothing of each other’s existence, but can share data via client-side cookies or a database (MySQL, DB2).

    HTTP Request
    Apache / IBM HTTP Server
          |            |
          |            |	  
        .php         .wss
          |            |
          v            v
         PHP          WAS

    This method is described by resources listed under section 4b in the Recommended PHP reading list.

  • Use the PHP Integration Kit to add PHP support to WebSphere Application Server Community Edition
    This option is probably the most straightforward and supported by IBM, but unfortunately it doesn’t apply to regular WebSphere Application Server, only the offering provided under the WAS name built on Apache Geronimo: WAS CE.

    This method uses a servlet filter within a preconfigured Java Web application to intercept requests for PHP scripts, and calls out to PHP via CGI. I haven’t experimented with this yet, though it is appealing because all the components are free and integration is done for you. I suspect there may be a performance bottleneck by using PHP as a CGI (in contrast to as an Apache module as described above). This method is also fairly new, by virtue of being an alphaWorks offering.

  • Use the PHP / Java Bridge
    I haven’t looked into this option yet, though it appears the focus here is actual application level interaction between Java and PHP, instead of separate, mutually exclusive PHP and Java applications which share a data store and web server.

    The communication between Java and PHP in an application server like WAS or Geronimo is managed by a Java library available from SourceForge. Like the second method above, communication with PHP is done via CGI.

    I’ll post an update once I explore this option in depth. The strength here seems to be the ability to share session data. A downside is that you have to intermingle Java with PHP code and vice versa.

  • Use an implementation of a PHP interpreter in Java
    OK, this option doesn’t actually exist for WebSphere, but it may be something that IBM decides to do in the future. All speculation, of course, since I don’t work in the Software Group and have no idea what they’re up to. Personally, I *wouldn’t* like to see it happen although other JEE vendors – BEA and Caucho – have taken this path.

    In this case, some Java code has been written to interpret code written in the PHP language. What this does is move away from the PHP interpreter source code (and its extensions!) which has been written in C and replaced them with Java. The perceived benefit here is that a 100% Java library to process PHP scripts can now be included with your JEE enterprise application.

    In my opinion this doesn’t make too much sense, since in this case vendors are trying to emulate the PHP interpreter as a new code base. Because PHP is modular and relies on many third party extensions which are also built in C, this would seem a maintenance nightmare and would always lag behind the official PHP interpreter.

    The “coolness” factor of this is what BEA and Caucho are probably weighing over the practicality of it. This appears to be more of an embedded option, which may be OK for providing core PHP language support, similar to how JME is a stripped down version of Java for mobile devices.

So there are four three options. The first option seems to be the most robust and flexible, but the second is probably the easiest to set up and maintain. Explore the options for yourself, and please post any other options here that I may have missed.