Spring and Grails apps on the Cloud

Some very interesting news from SpringSource this morning. They just continue to fire on all cylinders.

SpringSource has acquired Cloud Foundry, which enables you to set up the hosting environment for your Spring Framework and Groovy on Grails applications in minutes.

Cloud Foundry is built from the ground up to be the fastest way to deploy and manage Spring, Grails, and Java web applications in the cloud. Deployment using Cloud Foundry is a quick two-step process with the web application that you have created using the development tool of your choice:

  1. Upload your Spring, Grails, or Java web application to Cloud Foundry
  2. Select your deployment blueprint (topology, instance type, clustering, auto-scaling configuration, etc.) and launch it in Amazon Elastic Compute Cloud (EC2)

That’s it. Your application is now live and serving requests without fumbling with Amazon Web Services (AWS) APIs, bare-metal virtual machines, software installation and configuration, file transfers, and other tedious tasks.

So, instead of securing a hosting environment (whether through a third party service or in your own data center) you can provision space on the Cloud to eliminate the system, network, and middleware setup and maintenance steps.

In effect, it’s AOP writ large, abstracting away the cross-cutting middleware dependencies of your application into a separate component so you can instead focus on your business problem rather than many non-functional requirements.

In this way, I see this finally bridging the gap for small to medium sized applications that traditionally would rely on shared hosting for LAMP applications.

That is, as a freelancer or small agency you’ve now removed a major roadblock to deploying a small site on Spring or Grails rather than PHP and MySQL.

As of today, the Cloud Foundry instances for Spring support Apache 2.2, SpringSource tc Server (Tomcat 6) or Tomcat 5.5, and MySQL 5.0.

Though since this is all provisioned via Amazon’s EC2 service that supports DB2, I wonder how easy it would be to bring that data server into an application instance…

Very interesting indeed.

Chris Shiflett at NYPHP April 24th

23 April 2007 » Ajax, Apache, DB2, JavaScript, MySQL, PHP

New York PHP has officially lined up its next four monthly presenters:

The RSVP system for the April meeting tomorrow night is still open till 6pm EDT tonight. Hope you can make it.

Update: The RSVP deadline has been moved to midnight tonight.

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
          | 
          v
    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.

Published: Developing PHP Applications for IBM Data Servers

IBM has just published the Redbook that I wrote with a team of IBMers from across the globe in San Jose earlier this year.

The book had three goals; to demonstrate best practices for developing PHP applications with IBM database servers, to provide detailed instructions for administrators to set up all the required software, and to help users migrate from MySQL to DB2.

Developing PHP Applications for IBM Data Servers.

I expect you will all dedicate your long weekend to reading it. It makes an excellent beach or barbecue companion. :)

Public draft: Developing PHP Applications for IBM Data Servers

IBM has provided a public draft of the Redbook I wrote with a team of specialists in San Jose earlier this year. The book is undergoing a final editorial process to fix grammar, spelling and layout issues and to incorporate input from technical reviewers.

Please give it a read and pass your comments on to the editors via the feedback link on that page.

These pages are Web versions of IBM Redbooks- and Redpapers-in-progress. They are published here for those who need the information now and may contain spelling, layout and grammatical errors.

This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. Your feedback is welcomed to improve the usefulness of the material to others.

Pseudo-Slashdotting

After noticing a slight uptick in hits to a document on my own server from my article on Pairing J2EE with PHP to implement a common Web application infrastructure, I discovered that the article was linked from Slashdot this weekend. Not the main page unfortunately, but the Developer subsection. Cool nonetheless. :)

Article published in IBM WDTJ

An article I wrote for IBM’s developerWorks site went live this week with the May issue of the IBM WebSphere Developer Technical Journal.

The article argues that while PHP and WebSphere are generally considered competitors, they can work together to support a common type of application. The article covers the roles of a web application, where PHP and WebSphere fit in, and how to install them together with Apache and DB2 on a Linux server. I also provided a sample application as a proof of concept. The example code consists of a J2EE Struts application which serves as a content management system to a PHP-driven public website.

TAMPonS?

I’ve put together a simplified guide for installing Apache, MySQL, PHP, and Tomcat on Linux and Solaris. It’s not pretty, but it will get the job done.