Всем здравствуйте!

Разрабатываем корпоративный сайт компании. Почти на 100%решили, что будем использовать JetSpeed2. Пока только не можем определиться с платформой.

Выбираем между Apache Tomcat, Apache Geronimo, WebSphere Application Server.

Помогите определиться, какую платформу лучше всего выбрать и почему?

Всем заранее спасибо!

Учитывая что вам нужен только веб-контейнер, достаточно Tomcat. Geronimo и Websphere - серверы более тяжелые (Websphere - гораздо более тяжелый), к тому же в Geronimo вы получите Tomcat плюс кучу ненужной функциональности. Другое дело, если портал - это не единственное, что вы собираетесь хостить на сервере. Если там будут решения, использующий, например, EJB, то это другой разговор.

Дело ж в том, что EJB 2.1 использовать, я считаю, вообще не нужно. Есть же более легкие и быстрые решения: Spring, Hibernate... Тем более, что на подходе EJB 3.0, в котором как раз и будут использованы Spring и Hibernate... А в WebSphere AppServer, как я думаю, реализация EJB3 будет очень нескоро. Поэтому не вижу смысла в покупке WebSphere... Завяжемся на АппСервер, функционал которого мы не сможем использовать... И перейти никуда не сможем на другой сервер, так как деньги уже уплачены... Или я ошибаюсь?

Насчет денег думаю абсолютно прав. Какое же начальство даст поменять плаформу, в которую такие средства вложены.
А JBoss совсем не рассматривается? Тоже вполне себе production-ready, знаю примеры очень крупных банков, которые у себя в production его используют.

В общем так. На мой взгляд основные отличия JBoss и Geronimo от Websphere - это более скудная документация и отсутствие техподдержки (поскольку деньги не платили, но в принципе можно заплатить, поддержка будет и для них). Что касается поддержки, по заверениям знакомых она и в Штатах оставляет желать лучшего, а в РФ, думаю, вообще никакая. Так что не вижу никаких доводов в пользу Websphere, при том что функциональность примерно одинакова.

Относительно Tomcat vs JBoss и Geronimo. Если вы сейчас собираетесь разрабатывать только веб-приложения, то можно остановиться и на Tomcat, в конце концов JBoss и Geronimo - это Tomcat плюс другая функциональность (или Jetty плюс другая функциональность) и переехать при необходимости труда не составит. Но меня бы, например, Tomcat как production не устроил бы поскольку у него нет полноценного сервиса JNDI (о чем уже писалось в форуме) и JMS, которые я, бывает, использую.

Так что думайте

А что, вы используете EJB? Или JNDI еще где-то применяют?

Используем и EJB и JNDI. А без JNDI как? На него ведь в J2EE многое завязано.

Дело в том, что исследуя технологию EJB 2.1, я пришел к выводу, что использование ее есть неэффективным.
Во первых, hibernate и JDO являются более легкими и эффективными решениями для маппинга данных, по сравнению с сущностными EJB. Во-вторых, spring framework является легким и эффективным фреймворком, и, как мне кажется, его можно использовать взамен сесионных бинов.
В-третьих, технология EJB 3.0, которая на данный момент уже в состоянии final draft, включает в себя именно технологии hibernate и spring, как ядро технологии.
Именно поэтому считаю, что использование EJB 2.1 не имеет смысла, и поэтому есть смысл либо использовать EJB 3.0 в апп серверах по типу JBoss, или прикручивать spring/hibernate к существующим контейнерам сервлетов.
В любом случае не вижу большого смысла в использовании JNDI.
Поэтому и говорю, что не вижу смысла в использовании аппсерверов с EJB 2.1...
Если ошибаюсь, подскажите плиз, буду очень благодарен...

Готов подписаться под каждым словом. Просто дело в том, что у нас кой-какой софт начинал разрабатываться едва ли не в прошлом веке. Тогда, естественно, ни о каких Spring, Hibernate и т.п. и речи не было, все позднее появилось. Кроме того, общеизвестно как выглядит разработка веб-приложения с точки зрения Sun Microsystems, ну вот по тому пути и пошли. А приложения теперь хостить где-то надо. И вообще говоря, у EJB есть своя ниша - действительно большие системы, где нужна беспрецедентная масштабируемость, но в большинстве случаев EJB все-таки неоправданно используется.


А вот здесь не согласен. Для многих задач JNDI мне кажется наиболее подходящим решением. JNDI вообще говоря представляет собой систему каталогов, к которой можно обращаться удаленно. Вот один из примеров, где использование JNDI оправдано - комплекс приложений с общей системой безопасности. Если приложения деплоятся на разных хостах, то возникает проблема как хранить информацию о правах пользователя, вот тогда JNDI и придет на помощь. И это не единственный способ применения. Про JNDI можно здесь почитать - http://forum.vingrad.ru/index.php?showtopic=83074.

Неэффективным для чего?


Сущностные EJB предназначены отнюдь не только для маппинга данных из БД.

Только в двух серверах приложений есть более-менее сносная поддержка EJB3 - JBossAS и OracleAS. При этом пирог еще сырой. А использовать навесные framework'и на сервере - все равно, что ездить на грузовике в сортир. Так что пока для тех, кто использует сервера приложений, никаких альтернатив EJB2 нет и не предвидится еще как минимум в течение года.

Кстати, почему все называют hibernate или jdo технологией, тогда как первое - вполне определенный продукт, а второе - спецификация? Технология - ORM.

Это сообщение отредактировал(а) w1nd - 29.3.2006, 10:30

За линк спасибо!

Кстати, а не проще и эффективнее ли хранить информацию о правах пользователя в какой-нибудь БД?

Четыре довода в пользу JNDI в сравнении с использованием БД (при условии что это комплекс приложений с общей системой безопасности):

• в JNDI можно хранить обыкновенные объекты Java со всей информацией о правах пользователя, то есть отпадает этап преобразования "таблица БД - объект". Ну это, конечно, если абстрагироваться от того, как этот самый объект в JNDI попал
• если эти самые приложения используют разные СУБД (бывает такое), то это вынуждает некоторые из них работать с двумя СУБД сразу, не бог весть какой недостаток, но неприятно
• многие администраторы предпочитают не открывать БД вообще для удаленного доступа либо открывать только в нужном направлении. Тоже возможна проблема
• при условии использования одного и того же сервера приложений (одной реализации сервиса JNDI) не нужно никаких дополнительных драйверов и т.п.

Для написания большинства корпоративных систем. Технология тяжелая и сложная. Для каждой записи данных необходимо создавать тяжелый класс со своей транзакционностью, безопасностью и т.д... CMP очень ограничены в функционале выборки данных... При помощи BMP, например, для вытаскивания N записей нужно N+1 обращение к бекэнд системе, вместо одного.
И вообще: http://www.javable.com/javaworld/12_01/01/


конечно, еще и для маппинга в БД И для работы с нереляционными источниками. И для обеспечения транзакционности/безопасности (только это на уровне сущностных бинов в 99 процентах случаев не нужно)


А чем плохо использовать hibernate как "навесной framework"?


А что делать через год, когда выйдет EJB3, которая будет с принципиально-отличной архитектурой, чем EJB2? Переписывать все свои наработки за этот год? Нет уж, лучше использовать, пуская и не утвержденную, но EJB3, переделок при появлении спецификации будет при этом намного меньше...
И кроме того, лучше использовать хорошую нестандартизованную технологию hibernate, чем плохую специализированную EJB2.1, которая все равно скоро умрет...
Добавлено @ 11:48

Да, согласен, веские доводы...

Это сообщение отредактировал(а) Barvetal - 29.3.2006, 11:47

Не соглашусь. Именно для большинства корпоративных систем окромя EJB юзать нечего. Если, правда, вы имеете в виду приложение для браузинга БД, то, на мой взгляд, это не нельзя назвать "корпоративной системой".

Тяжести и сложности я вообще не усматриваю. Что сложного? Например, экскаватор много сложнее лопаты, так что - рыть котлован лопатой? Да это ни один заказчик оплачивать не станет. Сложно научиться использованию экскаватора? Не учитесь, не ройте котлованы, удовольствуйтесь клумбами, а котлованы будет рыть кто-то другой. Тестировать без сервера нельзя? Так ведь корпоративные системы на коленке не делаются и мощные сервера для разработки - данность.

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


Плохо тем, что не получится использовать давно существующие и отлаженные в серверах приложений механизмы кластеризации, мониторинга, управления и т. п. Плохо полным отсутствием поддержки со стороны производителя сервера. Да и сами подумайте: покупать ту же WebSphere ради того, чтобы прикрутить к ней hibernate и spring? Помилуйте.

И что значит - умрет? В день публикации финальной спецификации EJB3 ваше приложение работать перестанет, что ли? Кроме того, пока в реалиациях новой спецификации пофиксят все баги и вовсе тыща лет пройдет