In my previous post, I documented a scenario that I encountered while setting up a JSON view resolver in a Spring MVC project.  Let me take a step back and explain my motivations for why I wanted a JSON view resolver.

In any Spring MVC application, Controller classes are responsible for processing some data, then returning a ModelAndView .  Typically views eventually return HTML either directly from a JSP or through a templating framework like Tiles.  However, custom views  can provide output such as Excel or PDF files.  In my case, I wanted an easy way to return a JSON response from certain Controller methods that would be called from an Ajax request.

HTML is a perfectly valid response to an Ajax request; often the Javascript processes an HTML response and then inserts the HTML into a page.  But occasionally JSON makes more sense, like when a page simply needs to know something about what is going on back on the server without displaying anything to the user(for example, whether the user has a valid session that has not timed out).  JSON is the native format of Javascript, so it is a convenient way to return a response to a Javascript client.

I found a great project called Spring Json View that offers all the features of Spring MVC like validation, exception handling, and error handling and automatically converts the Model to a JSON object.  It was probably a bit more than I needed for what I was trying to accomplish, but I was working on an internal company project and one of our secondary goals was to build skills and identify patterns that would be useful on future projects.  So I tested it out for this simple scenario, and I expect that this pattern could be useful on future projects.

Check out the configuration snippets from my previous post to see how I integrated Spring Json View into Spring MVC.

Also, here’s a quick example of how a controller method can use it:

@RequestMapping(method = RequestMethod.GET)
public ModelAndView isLoggedIn(ModelMap model) {
model.addAttribute("loggedIn",
!SecurityContextHolder.getContext().getAuthentication().getName().equals("guest"));
return new ModelAndView("jsonView", model);
}

As part of an upcoming project, I have been doing some research and coding trying to understand some of the various methods of integrating Java into a PHP environment. We can categorize the methods into three basic areas: The use of Web Services, utilizing a VM Bridge, and Direct Calling. We also take a look at another alternative, which is running PHP in a Java Environment. I will briefly describe the features of each method, giving those looking for such tools some insight as to what may best fit their application.

Web Services

Since there are many various forms of web services, I have focused my research on two commonly accepted methods.

SOAP (have a working prototype available)

• Uses direct calls of Java functions via Java web service from within PHP
• Can maintain independent Java & PHP environments
• Uses Apache AXIS / AXIS 2 framework, but can be adapted for other web service platforms
• SOAP is built into PHP5, but there are popular third party modules for older versions of PHP
• Have the ability to use normal Java classes then auto-generate the service and a client with JUnit tests from within Eclipse JEE
• Features an optional online management interface in AXIS2 to disable, enable, or monitor services as needed
• Java RESTful Web Service with Jersey using JSON passing (have a working prototype available)
• Can maintain independent Java & PHP environments
• Requires more coding on the PHP side with independent requests to individual methods and handling JSON objects
• JSON is built into PHP5 but may require third party libraries for older versions
• Requires more coding on Java side with annotations and passing JSON objects; not plain Java objects
• There are many libraries available for RESTful Service in Java, Jersey is only used as a reference
• Is the slowest tested method due to slow http requests in PHP (1/5 second per call)
• Can be optimized if only a single http request is required per page

VM Bridge. A bridge uses “continuation passing” to invoke procedures/methods from each environment maintaining their individual properties.

php-java-bridge.sourceforge.net (have a working prototype available)

• Can maintain independent Java & PHP environments
• Much faster than methods implemented above. (In my tests: 2-3x that of SOAP, 10x that of rest services with multiple requests) (Authors claim: 50x improvement over SOAP/XML-RPC)
• Uses a VM Bridge XML Network Protocol behind the scenes to communicate with remote or local JVM running a Java app, or Java servlet
• Have the ability to program regular Java classes
• Can directly call Java functions in PHP (Works with apache or IIS)
• Listed as the only free alternative to Web Services/XML-RPC
• http://php-Java-bridge.sourceforge.net/pjb/index.php

Zend Platform PHP Java Bridge

• Similar to the above product but a commercial package bundled as part of the Zend Platform.
• Offers a similar API as the above product.
• http://www.zend.com/en/products/platform/product-comparison/Java-bridge

Direct Calling

By far the simplest method for using Java in PHP, it can load java classes directly and call its methods. This is not without its drawbacks however.

Direct Java calling within PHP5

• This is an experimental feature of PHP5
• Authors say to use at own risk
• http://us.php.net/manual/en/intro.Java.php

Running PHP in a Java Environment. The methods described below attempt to emulate a specific PHP version entirely in Java. This has the potential of being very fast and easy, however may not meet integration requirements.

Caucho Resin J2EE Application Server with PHP Integration

• Runs PHP scripts fast (claim a 6x improvement in speed over apache with PHP)
• The entire PHP implementation is built in Java
• Not entirely all features of PHP have been implemented, may have issues with multi-threading
• Requires only one server and environment
• Have the ability to use regular Java classes
• May have to adapt current PHP code for a Java environment
• Is a good way to transition developers from PHP to Java
• http://www.caucho.com/resin-3.0/quercus/

Tomcat PHP Java Servlet SAPI

• Enables the entire PHP processor to be run as a servlet
• PHP has a habit of changing the working directory and may not be able to load any classes from the relative CLASSPATH
• Requires only one server and environment
• Have the ability to use regular Java classes
• PHP version 5 is not currently supported
• May have to adapt current PHP code for a Java environment
• http://us.php.net/manual/en/Java.servlet.php

For more information on any of the above methodologies or to request sample code, please don’t hesitate to contact me at: dtalk@credera.com