codemash - caffienated php - php java bridge

January 19, 2007

I’m attending the caffienated php session - this will demonstrate the java/php bridge. This is put on by Kevin Schroeder from Zend.

Kevin started off by giving a rundown of Zend - products, services, etc. No mention of ZendFramework project (yet?).

Why use PHP and Java together? PHP is easier for most tasks, and Java can fill the missing gaps. PHP/Java bridge lets you extend PHP without building a C-based module.

Three options - use sourceforge code, compile module in to PHP.

Native Java interface in PHP4, but it spawned new JVM on each request.

Third option - use Zend platform Java bridge. It’s not just a container for Java bridge - GUI config, job queues, BIRT reporting, SNMP integration, session clustering, event monitoring, and more. These are all in Zend Platform 3 - in beta and downloadable now.

Zend platform offers file download acceleration - passes off certain files to another web serving process (not apache) - frees up your Apache process for more CPU intensive work.

Something I wonder - should ask too - does Zend platform allow for web services integration? Given the custom event triggers and whatnot it offers, offering web service integration hooks would be useful, imo.

< ?

header("Content-type: text/plain");

$system = new Java("java.lang.system");

var_dump($system);

$system->getProperties() would return an Object, but var_dump prints an associative array.

String = string but StringBuffer and Builder remain Java objects

Integer = int

Long = floar

Java arrays are converted to PHP arrays

All other objects retain status as Java obejcts and can be called as such in PHP code

$java->getEntry(”foo”);

Examples of resource pooling using LDAP, resourced persistence using IMAP, async execution using multi-threaded queue.

A ‘java bridge’ for pooling resources is nice and all, but it raises the question in my mind of why the ‘persistent connection’ pattern wasn’t implemented for PHP’s LDAP and IMAP modules. It seems the pconnect approach is not welcomed these days (I think it’s removed from PHP5’s mysql code, or perhaps that’s mysqli?), but these modules have been around for years. Why didn’t anyone create IMAP_pconnect or LDAP_pconnect functions years ago?

The examples he’s giving for LDAP and IMAP both show that PHP is a bit faster, but the respective servers are hit very hard, whereas with the pooling approach there’s no utilization on the servers. This indicates that the hit is biggest during the connection handshake and any authentication.

Kevin indicated that because IMAP is generally specific to each user for authentication (as opposed to db or ldap connections) it wouldn’t make sense to pconnect those - just too wasteful.

Did you like this post? Buy me a hot chocolate!

Category Posted in Conferences, Java, Language, PHP, Uncategorized