Using Java server-side with PHP-generated front-end

 Does anyone have a real-world experience in building such a project? I'd like to move away questions about "is it good idea or not", but focus on possible solutions. I see one simple way - HTTP GET/POST + xml/json - and one more elegant - AJAX/DWR. As for the first one - I understand that it is possible, but needs quite a lot coding. As for second way - is it possible to use Java DWR engine with PHP front-end? Is DWR language-independent for client side (as it uses just JavaScript)?

 Would it be a problem, that client page was generated by one web server (for example, apache+php) and served on server-side by another (f开发者_运维问答or example, tomcat)? I suspect, that Tomcat will complain about sessions. Can this problem be fixed with allowing cross-domain AJAX?

Thank you in advance.

Denis.

If what you want to do is (as I suspect) to use PHP to assemble your web pages while the "business logic" is written in Java, I would suggest using PHP/Java Bridge (LGPL and MIT licenses)

Both Java and PHP are server-side technologies. Your "front-end" will be written using HTML, CSS, and JavaScript - although you could certainly use PHP (or JSP) templates to render portions of the front-end.

If you are using PHP as the "front-end", then you would need it to act as a proxy, passing requests back to the Java web server.

I've worked on a project that uses a Java 'backend' and a mod_perl 'frontend'. For the naysayers, this is because the Java is providing service/API facilities, it's not and shouldn't be involved in dealing with UI, be they HTML, WAP, SMTP, SOAP, etc.

For historical reasons the mod_perl talks XML-RPC. It's not a route I'd recommend at this stage. Java, Perl and PHP can quite happily handle far more JSON type transactions due to lower encoding/decoding overhead. Also, in a mod_perl (though not PHP) environment it's possible to run JSON-RPC easily over a persistent connection, reducing the overhead even further.

There are plenty of benefits to this approach, including separate upgrades to the various UIs, stability of the service layer, and distinct responsibilities for each layer.

Downsides include delays getting service improvements live, more complicated development, staging and test environments, a taller barrier to entry for new developers, more documentation and management.

For the "Java front to back" guys, this is a similar type approach to using an OSGi container, only using more domain suitable languages; Java for heavy lifting, scripts for more fluid, text based interfaces.