Использование Java на стороне сервера с созданным PHP интерфейсом - PullRequest
3 голосов
/ 09 июня 2010

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

Ответы [ 3 ]

2 голосов
/ 09 июня 2010

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

2 голосов
/ 09 июня 2010

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

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

1 голос
/ 09 июня 2010

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

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

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

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

Для ребят из «Java front to back» этот подход подобен типу использования контейнера OSGi, только с использованием более подходящих для домена языков;Java для тяжелой работы, скрипты для более гибких текстовых интерфейсов.

...