RE: [Php-java-bridge-users] Communication with a foreign existing JVM

[<php...@li...>]

Hi,


> It is possible to run a persistent JVM (through
> http://php-java- 
>
bridge.sourceforge.net/server/documentation/API/php/java/bridge/
> 
> JavaBridge.html) BUT this VM will be managed by the
> bridge 

not by the bridge, by the container. In most cases
this is a web container (servlet engine, j2ee server,
...), but it could also be a standalone container
(started by the php-java-bridge.service script) or
even be native code (if GNU java is used).

In any case, the bridge back-end running in the
container can communicate with the "business objects"
(EJB beans, ...) deployed into a J2EE server using
standard java technology (e.g.: rmi/iiop).

All j2ee applications servers have a web tier and an
ejb tier, so all you need to do is to deploy
JavaBridge.war into the web tier. After that you can
easily query the remote interfaces of the EJB beans
running in the ejb tier and call them.
 
> thus It is IMPOSSIBLE for the php.java.bridge to
> discover objects  
> living in a independent & persistent JVM 

It is certainly possible to discover web services or
invoke enterprise java beans in a second JVM. In fact
this three tier architecture is what makes caching,
connection pooling etc. possible.


> For this, I would need ie to create a XML-RPC server
> on the Java side  

Or RMI/IIOP, which is probably easier, see
http://php-java-bridge.sourceforge.net/examples/J2EE/
for details.


> If there is another way to look at the problem with
> the php.java.bridge

For trivial applications one could get away by using
only one java VM, but this whould be less efficient.
The low-level PHP/Java Bridge XML protocol works best
when the php continuation and the java continuation
run on the same computer and communicate via shared
memory.

On the other hand the high-level communication on
application level doesn't need a low-latency comm.
link. You serialize and send complete object graphs
anyway, so on app. level you care more about bandwidth
than latency.  Therefore XML-RPC would be the wrong
technology on this level, imho.


Regards,
Jost Boekemeier



		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de