views:

1499

answers:

9

I am implementing a website using PHP for the front end and a Java service as the back end. The two parts are as follows:

  1. PHP front end listens to http requests and interacts with the database.

  2. The Java back end run continuously and responds to calls from the front end.

More specifically, the back end is a daemon that connects and maintain the link to several IM services (AOL, MSN, Yahoo, Jabber...).

Both of the layers will be deployed on the same system (a CentOS box, I suppose) and introducing a middle layer (for instance: using XML-RPC) will reduce the performance (the resource is also rather limited).

Question: Is there a way to link the two layers directly? (no more web services in between)

+1  A: 

You could try the PHP/Java integration.

Also, if the communication is one-way (something like "sendmail for IM"), you could write out the PHP requests to a file and monitor that in your Java app.

Piskvor
The communication is actually two-way. However, even when it's one way then we still need to deal with file locking as well. It could be solved by using a named pipe but that's still considered a middle layer.
ThoaiOnline
From the Introduction: "Warning: This extension is EXPERIMENTAL. The behaviour of this extension including the names of its functions and any other documentation surrounding this extension may change without notice in a future release of PHP. This extension should be used at your own risk."
David Rabinowitz
It's been experimental for a few years now - which I read as "abandoned". It's a middle layer anyway - I'm not sure if it is actually possible to make Java and PHP interface directly without a) using some middle layer or b) writing your own.
Piskvor
+6  A: 

Since this is communication between two separate running processes, a "direct" call (as in JNI) is not possible. The easiest ways to do such interprocess communcation are probably named pipes and network sockets. In both cases, you'll have to define a communication protocol and implement it on both sides. Using a standard protocol such as XML-RPC makes this easier, but is not strictly necessary.

Michael Borgwardt
A: 

I've come across this page which introduces a means to link the two layers. However, it still requires a middle layer (TCP/IP). Moreover, other services may exploit the Java service as well because it accepts all incoming connections.

http://www.devx.com/Java/Article/20509

[Researching...]

ThoaiOnline
You should edit your question rather than answering it. And as I wrote, it's not possible for two separate processes to communicate without SOME sort of intermediate layer. As for access from the outside, that's what firewalls are for, but a named pipe would not exhibit this problem.
Michael Borgwardt
+2  A: 

I have tried PHP-Java bridge(php-java-bridge.sourceforge.net/pjb/) and it works quite well. Basically, we need to run a jar file (JavaBridge.jar) which listens on port(there are several options available like Local socket, 8080 port and so on). Your java class files must be availabe to the JavaBridge in the classpath. You need to include a file Java.inc in your php and you can access the Java classes.

Naveen
+2  A: 

Sure, there are lots of ways, but you said about the limited resource...

IMHO define your own lightweight RPC-like protocol and use sockets on TCP/IP to communicate. Actually in this case there's no need to use full advantages of RPC etc... You need only to define API for this particular case and implement it on both sides. In this case you can serialize your packets to quite small. You can even assign a kind of GUIDs to your remote methods and use them to save the traffic and speed-up your intercommunication.

The advantage of sockets usage is that your solution will be pretty scalable.

Jet
+2  A: 

There are generally four patterns for application integration:

  1. via Filesystem, ie. one producers writes data to a directory monitored by the consumer
  2. via Database, ie. two applications share a schema or table and use it to swap data
  3. via RMI/RPC/web service/any blocking, sync call from one app to another. For PHP to Java you can pick from the various integration libraries listed above, or use some web services standards like SOAP.
  4. via messaging/any non-blocking, async operation where one app sends a message to another app.

Each of these patterns has pros and cons, but a good rule of thumb is to pick the one with the loosest coupling that you can get away with. For example, if you selected #4 your Java app could crash without also taking down your PHP app.

I'd suggest before looking at specific libraries or technologies listed in the answers here that you pick the right pattern for you, then investigate your specific options.

rcampbell
A: 

Sorry, this is a bit of a quick answer but: i heard the Resin app server has support for integrating java and PHP.

They claim they can smash php and java together: http://www.caucho.com/resin-3.0/quercus/

I've used resin for serving J2ee applications, but not for its PHP support.

I'd be interested to hear of such adventures.

Ash Kim
A: 

Why not use web service?

Make a Java layer and put a ws access(Axis, SpringWS, etc...) and the Php access the Java layer using one ws client.

I think it's simple and useful.

Vudko
I want something really minimal. For a VPS with limited resources (around 256MB of RAM), it's ok to use ws for 10 connections, but 1000 connections will make it a big problem. Thinking about scalability at minimum cost.
ThoaiOnline
+1  A: 

I was also faced with this problem recently. The Resin solution above is actually a complete re-write of PHP in Java along the lines of JRuby, Jython and Rhino. It is called Quercus. But I'm guessing for you as it was for me, tossing out your Apache/PHP setup isn't really an option.

And there are more problems with Quercus besides: the free version is GPL, which is tricky if you're developing commercial software (though not as tricky as Resin would like you to believe (but IANAL)) and on top of that the free version doesn't support compiling to byte code, so its basically an interpreter written in Java.

What I decided on in the end was to just exchange simple messages over HTTP. I used PHP's json_encode()/json_decode() and Java's json-lib to encode the messages in JSON (simple, text-based, good match for data model).

Another interesting and light-weight option would be to have Java generate PHP code and then use PHP include() directive to fetch that over HTTP and execute it. I haven't tried this though.

If its the actual HTTP calls you're concerned about (for performance), neither of these solutions will help there. All I can say is that I haven't had problems with the PHP and Java on the same LAN. My feeling is that it won't be a problem for the vast majority of applications as long as you keep your RPC calls fairly course-grained (which you really should do anyway).

Ramon
When Java generates you're PHP code, the resulting PHP code will be different each time it run's. Thus depending how PHP opcode caching exactly works, this solution has a high change of disables PHP caching (APC, eAccelerator, etc) and thus degrading performance for all scripts that include this java generated PHP code.
Kdeveloper