Когда использовать EJB ?

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

0

Масштабируемость системыю, load balancing (кто знает как переводится этот термин?), поддержка распределенных транзакций...

Список можно продолжать, но это первое что пришло сходу в голову.

С уважением, Владимир

0

Да, это все я читал в книжке ... но масштабируемость и лоад балансинг это все таки наверно не функциональные требования ... а вот про поддержку распределенных транзакций мне и интересно было узнать ...
Из каких требований ты вывел её необходимость в своем проекте ???
напиши немного подробней ....

0

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

0

Я думал как-то об этом, и нашел только два аргумента в пользу EJB. Точнее EJB без CMP, то есть только Session Beans. Аргументы следующие:
1) Имеет смысл использовать EJB для локализации бизнес логики. Другими словами, формируется множество сервисов, к которым в дальнейшем подключаются как минимум два клинта разного ТИПА. Таким образом, EJB -- множество сервисов.
2) В подавляющем большинстве приложений EJB используются с единственным клиентом -- веб-клиентом. И крутится все это на одной физической машине (под одной машиной я понимаю компьютер с общим ОЗУ). Следовательно все ресурсы компьютера разделяются между Servlet-контейнером и EJB-контейнером. При большой загрузке имеет смысл вынести бины на физичеки отдельную машину.

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

Вот такие у меня мысли )

0

>load balancing
Хм интересно
может быть управление загруженностью, но кАрЯво как то звучит

0

чисто навеяло....
как то уже эта тема поднималась.
Если у вас предполагается невероятное воличество транзакций то EJB(неважно Sessionbeans или EntityBeans) необходимы потому как распределение оных дело ресурсоемкое.Но если например одномоментно 100 юзеров будут чего то там вытворять на сервере то проще javabean с scope=session для каждого юзверя,времени займет гораздо меньше,не надо писать кучу файлов, компилять их, джарить, потом деплоить ...А не дай Бог чего не так то повторять процедуру в том же порядке.....
Чиста с под грузинского полусухого такие мысли посетили

а Load balancing скорее всего загрузка балансировки(или уравновешивания что есть более по русски)

'балансировка загрузки' предлагаю )

0

...или нагрузки

0

2Danissimo:

Если большая нагрузка, то что мешает сделать кластер из обычного WAR?

2All:

Да распределенные транзакции это круто, а кто-нибудь их реально использовал? И вообще какой в них смысл, если можно опять же использовать кластер, там как я понимаю транзакция полностью выполняется на одной машине.

Единственно чего обычным классам до EJB далеко, так это security и пул объктов(хотя это можно и самому реализовать, но на это нужно дополнительное время, которого всегда нехватает)

Так что бум EJB прошел? Как вы считаете?

0

про распределенные транзакции.

конкретная ситуация - веб клиент отсылает JMS сообщение в очередь, которую обрабатывает MDB, обращающийся к 4-5 (минимум) компонентам (EntityBeans, DAO, etc.).

для подобного сценария (тут не все детали описаны, но это реальный пример) технически необходима поддержка XA-протокола и для JMS провайдера, и для драйвера базы данных (+ коннекторы JCA, если таковые используются).

если такового не будет - сыпем кучу ошибок + неизвестно, что у нас будет с данными и логикой дальше.

0

Пример распеределенных транзакций? пожалста - ebay.com(самый крупный веб-аукцион) сидит на WebSphere если верить рекламе от IBM )))
Пик на EJB? Это немного непонятно.... Самого пика по себе не было в принципе.Если компания понимала что ей это надо она это делала если нет то и не надо....

Про транзакции мне понравилось )

Давайте обощим ответ на исходный вопрос: 'Что должно быть в функциональных требованиях к системе, чтобы ее предпочтительней было реализовывать используя EJB?'

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

Интерактиыне системы доступа к точкам управления бизнес-процессами формируют события. Именно события являются движущей силой процессов, они переводят систему в целом из состояния в состояние. Так вот, чтобы ответить на вопрос, нужно понять, насколько требования к процессу обработки событий сочетаются со свойствами и возможностями EJB.

Согласитесь, что чаще всего состояние системы хранится в БД. Пусть в распределенной. Что мешает весь процесс обработки событий разместить там же -- в БД? Интеграция с другими системами легко выносится на уровень интерактивности. Зачем здесь EJB? Асинхронная обработка событий -- реализуемо. Распределенные транзакции -- реализуемо, секьюрити -- тоже. Другой вопрос, что дешевле: реализовывать на каком-нибудь PL/SQL или на Java.

Теперь рассмотрим системы с гетерогенной памятью состояний. Крайне маловероятно, что системы, расчитанные на гомогенное взаимодействие, такие, как СУБД, будут успешны в гетерогенном. В этом случае без связывающего уровня не обойтись. Вот тут-то EJB как нельзя кстати. Вот -- первый случай оправданного использования EJB.

А что делать, если, отвечая на вопрос, что дешевле, Java оказалась дешевле. Если PL/SQL, то понятно, что делать. С Java не все так просто. Модно ведь написать EJB, а можно обычные классы. Критерием, который определит, что же делать, я бы выделил следующее: сколько ТИПОВ клиентов будет у уровня доступа бизнес процессов. Если 2 и больше, то EJB предпочтительнее. Причем исключительно из соображений удобства, как мне кажется.

Как вы считаете, ответ верный, полный? Или требуются дополнения? Милости просим )

0

А что это (если не затруднит ) - 'гетерогенная память' и 'гомогенное взаимодействие' ?

0

Пример: система на событие должна осуществить проводку по внутренним счетам-справочникам и делегировать внешней платежной системе реальное перечисление средств. Память состояний системы распределена по разородным хранилищам -- гетерогенная память. Но СУБД расчитаны в подавляющем большинстве случаев на взаимодействие с себе подобными системами. Совокупность таких систем есть однородная или гомогенная система.

0