有人有构建这样的项目的实际经验吗？我想摆脱“这是否是好主意”的问题，而是关注可能的解决方案。我看到一种简单的方法 - HTTP GET/POST + xml/json - 以及一种更优雅的方法 - AJAX/DWR。至于第一个 - 我知道这是可能的，但需要大量编码。至于第二种方式-是否可以将Java DWR引擎与PHP前端一起使用？ DWR 是否与客户端语言无关（因为它只使用 JavaScript）？
如果客户端页面由一台 Web 服务器（例如 apache+php）生成并由另一台 Web 服务器（例如 tomcat）在服务器端提供服务，这会是一个问题吗？我怀疑 Tomcat 会抱怨会话。这个问题可以通过允许跨域 AJAX 来解决吗？
预先感谢您。
丹尼斯.
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 (for 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.
发布评论
评论（3）
如果你想做的是（正如我怀疑的那样）使用 PHP 来组装你的网页，而“业务逻辑”是用 Java 编写的，我建议使用 PHP/Java Bridge（LGPL 和 MIT 许可证）
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)
Java和PHP都是服务器端技术。您的“前端”将使用 HTML、CSS 和 JavaScript 编写 - 尽管您当然可以使用 PHP（或 JSP）模板来呈现前端的部分内容。
如果您使用 PHP 作为“前端”，那么您需要它充当代理，将请求传递回 Java Web 服务器。
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.
我参与过一个使用 Java“后端”和 mod_perl“前端”的项目。对于反对者来说，这是因为 Java 提供服务/API 设施，它不会也不应该参与处理 UI，无论是 HTML、WAP、SMTP、SOAP 等。
出于历史原因，mod_perl 谈论 XML-RPC 。这不是我现阶段推荐的路线。由于编码/解码开销较低，Java、Perl 和 PHP 可以非常愉快地处理更多 JSON 类型的事务。此外，在 mod_perl（尽管不是 PHP）环境中，可以通过持久连接轻松运行 JSON-RPC，从而进一步减少开销。
这种方法有很多好处，包括对各个 UI 的单独升级、服务层的稳定性以及每个层的不同职责。
缺点包括服务改进的延迟、更复杂的开发、登台和测试环境、新开发人员的进入门槛更高、更多的文档和管理。
对于“Java 从前到后”的人来说，这是与使用 OSGi 容器类似的类型方法，只是使用更适合领域的语言； Java 用于繁重的工作，脚本用于更流畅、基于文本的界面。
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.