Я работал над проектом, который использует 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 для тяжелой работы, скрипты для более гибких текстовых интерфейсов.