Использование серверной части Java с внешним интерфейсом, созданным на PHP.

Question

Есть ли у кого-нибудь реальный опыт создания такого проекта?Я бы хотел отойти от вопросов «хороша это идея или нет», а сосредоточиться на возможных решениях.Я вижу один простой способ — HTTP GET/POST + xml/json — и еще один элегантный — AJAX/DWR.Что касается первого - я понимаю, что это возможно, но требует довольно много кодирования.Что касается второго способа, можно ли использовать движок Java DWR с интерфейсом PHP?Является ли DWR независимым от языка на стороне клиента (поскольку он использует только JavaScript)?
Будет ли проблемой то, что клиентская страница создается одним веб-сервером (например, apache+php) и обслуживается на стороне сервера другим (например, Tomcat)?Подозреваю, что Tomcat будет жаловаться на сессии.Можно ли решить эту проблему, разрешив междоменный AJAX?
Заранее спасибо.
Денис.

Answer 1

Если вы хотите (как я подозреваю) использовать PHP для сборки ваших веб-страниц, в то время как «бизнес-логика» написана на Java, я бы предложил использовать PHP/Java-мост (лицензии LGPL и MIT)

Answer 2

И Java, и PHP являются серверными технологиями.Ваш «интерфейс» будет написан с использованием HTML, CSS и JavaScript, хотя вы, безусловно, можете использовать шаблоны PHP (или JSP) для визуализации частей интерфейса.

Если вы используете PHP в качестве «интерфейсного интерфейса», вам понадобится, чтобы он действовал как прокси, передавая запросы обратно на веб-сервер Java.

Answer 3

Я работал над проектом, в котором используется «бэкэнд» Java и «интерфейс» mod_perl.Для скептиков это связано с тем, что Java предоставляет средства обслуживания/API, а не для работы с пользовательским интерфейсом, будь то HTML, WAP, SMTP, SOAP и т. д.

По историческим причинам mod_perl использует XML-RPC.На данном этапе я бы не рекомендовал этот маршрут.Java, Perl и PHP вполне могут обрабатывать гораздо больше транзакций типа JSON из-за меньших затрат на кодирование/декодирование.Кроме того, в среде mod_perl (хотя и не PHP) можно легко запускать JSON-RPC через постоянное соединение, что еще больше снижает накладные расходы.

У этого подхода есть множество преимуществ, включая отдельные обновления различных пользовательских интерфейсов, стабильность уровня обслуживания и отдельные обязанности для каждого уровня.

К недостаткам можно отнести задержки с внедрением улучшений сервиса, более сложную среду разработки, промежуточного тестирования и тестирования, более высокий входной барьер для новых разработчиков, больший объем документации и управления.

Для парней, работающих на Java, это подход, аналогичный использованию контейнера OSGi, только с использованием большего количества языков, подходящих для предметной области;Java для тяжелой работы, сценарии для более гибких текстовых интерфейсов.