Как сохранить минимальную зависимость приложения от сервера?
Каков наилучший (самый простой, наиболее простой) способ построения Java-приложения, при этом как можно меньше полагаясь на фактический сервер приложений, используемый в развертывании?
Например, скажем, я хочу развернуть на Apache Geronimo, а позже хочу использовать GlassFish, насколько сложным будет переход? Как лучше всего абстрагироваться от использования каждого сервера приложений?
Извините мое невежество, я относительно новичок в разработке Java. Я хочу начать новый проект, но не уверен, стоит ли его использовать. отдельные API для функциональности, которая мне нужна или разрабатывается поверх выбранного сервера приложений с самого начала.Спасибо за помощь,
Иван
4 ответа:
Не вдаваясь в слишком много деталей, даже если вы можете написать голый код Java EE, конфигурация вокруг него не очень проста. Каждый сервер приложений имеет свой собственный набор конфигурационных файлов и соглашений об именовании (например, формат указания местоположения AS отличается в IBM WAS и в JBOSS). Хотя они не очень важны для разработки приложений, как только вы перейдете к этапу развертывания, они станут важными. Что касается библиотек и вашего код беспокоит до тех пор, пока вы придерживаетесь стандартов EJB, вы сможете запускать свое приложение на большинстве серверов приложений (я знаю о WAS и JBoss - код, который я написал, не должен был меняться для этих серверов; конфигурация, хотя, Ну, это был другой зверь !).
Следуйте спецификации Java EE как можно больше, в то время как следуйте спецификации сервера как можно меньше.
Если мы попытаемся выяснить, что является общим среди серверов приложений Java EE (JBoss, был ...), ответ-спецификация Java EE, которой должны следовать поставщики серверов. Если у вас есть 2 решения проблемы Java EE, вы можете проверить, какое решение лучше соответствует спецификации Java EE, а не спецификации сервера.
Из моего опыта работы с Jboss и Sun AS, вы должны просто забыть о as-независимости.
В sql, например, можно сделать довольно много без использования специфичных для поставщика функций. Ну, это не так в Java EE. Для Jboss и SAS даже приложения "hello world" требуют другой конфигурации. И чем больше растет приложение, тем больше специфичных для поставщика функций вы должны использовать.
В частности, если вы посмотрите на официальный учебник Sun Java EE, вы обнаружите, что он использует Файлы конфигурации SAS-specific (sun-web.xml, sun-ejb-jar.xml и т.д.) С самого начала.
Но все вышесказанное применимо только в том случае, если вы используете полный спектр функций Java EE (таких как EJB, JMS, MBean). Я обнаружил, что если у вас есть только сервлеты/JSP, упакованные в один военный архив, такое приложение все еще может быть очень портативным.
Если у вас есть ресурсы, то подумайте о разработке и тестировании для нескольких серверов приложений, а не только для вашего первоначального целевого сервера. Это позволит вам - с самого начала-точно определить вещи, которые необходимо настроить и соответственно закодировать.
Лично я рассматривал бы Glassfish 3.0.1 в такой ситуации, поскольку это эталонная реализация, поэтому вещи должны, по крайней мере, работать там без каких-либо особых усилий.