Здравствуйте, mselez, Вы писали:
ND>>получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
M>где-то читал, что EJB полезна в 5-10 % случаев , в остальных лучше обойтись более простыми решениями типа Spring + Hibernate
здесь надо все-таки четко сказать — речь о EJB вообще или об Entity EJB в частности?
т.к. есть задачи, для которых Session EJB являются практически единственным стандартным переносимым подходом.
например, система, доступ к которой производится не только через Web GUI, а также через утилиты командной строки, свинг-клиенты. здесь Session EJB помогает для переносимого решения защиты этой системы от несанкционированного доступа на всех уровнях приложения, т.к. JAAS для всего этого хозяйства довольно неплохо специфицирован.
+ стоит помнить про message-driven beans
1) Это IoС контейнер, со всеми вытекающими последствиями.
2) Он предоставляем свой AOP фреймворк.
3) Он имеет модульную архитектуру (если честно, когда читаешь его код — сердце радуется. Вот где верх изящества построения архитектуры.)
По этому
C0s>как в Spring сделаны а) декларативный security
В спринг они не сделаны. Но.... Специально для спринг разработан acegi security framework, который призван обеспечить декларативный security. При чем не просто code-principal-based а так же и code-principal-subject-based. Что для этого надо? Надо просто придерживаться нескольких простым принципов проектирования проповедуемых Spring (прогарммирвание с использованием интерфейсов, использование голивудского принципа, ну может еще что-то но сейас это не важно. Важно то что сприг поддерживает такой стиль разработки).
C0s>б) как там с прозрачной транзакционностью
вот с этим спринг справляется самостоятельно. Причем он обеспчивает прозрачную транзакционность как в случае с local transacions так и в случае с JTA транзакциями. Причем использование того или иного механизма транзакций можно изменить не меняя ни строчки кода. Просто надо подкрутить файл конфигурации бинов.
C0s>в) как там насчет прозрачной распределенности
не совсем понятно что имеется ввиду под "прозрачной распределенностью". Если придерживаться принципов проектирования проповедуемых Spring то можно объявить нужную функциональность в виде интерфейса, а реализацию этой функциональности настроить с использованием конфигурационного файла. Спринг предоставляет несколько реализаций remouting (через rmi, jaxrpc, Caucho's HTTP-based Hessian and Burlap protocols + можно добавить люую свою реадизацию). При этом польхователю функциональности ничего не изветно о том как она реализована.
Здравствуйте, NorthDragon, Вы писали:
ND>получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
Боюсь навлечь на себя гнев праведный, но EJB дрова еще те
Кто может что сказать по поводу производительности сабжевых бинов. бины BMP. предпологаемое количество одновременно крутящихся на сервере — 1500 одного класса и еще 30 000 второго. примерный обьем данных которые в бинах хранятся 500-600 мб .
Т.е есть путь юзать хранимые процедуры. либо юзать бины. количество пользователей в системе в районе 1500-3000. или ссылочки где про это можно прочитать. и как их производительность увеличить. есть ли Альтернативы.
Здравствуйте, NorthDragon, Вы писали:
ND>Кто может что сказать по поводу производительности сабжевых бинов. бины BMP. предпологаемое количество одновременно крутящихся на сервере — 1500 одного класса и еще 30 000 второго. примерный обьем данных которые в бинах хранятся 500-600 мб . ND>Т.е есть путь юзать хранимые процедуры. либо юзать бины. количество пользователей в системе в районе 1500-3000. или ссылочки где про это можно прочитать. и как их производительность увеличить. есть ли Альтернативы.
Альтернартивы есть всегда. Особенно в этом случае. Почитать в Expert One-on-One J2EE without EJB.
Плюс посмотреть на Hibernate.
Здравствуйте, Lucker, Вы писали:
L>Здравствуйте, NorthDragon, Вы писали:
ND>>Кто может что сказать по поводу производительности сабжевых бинов. бины BMP. предпологаемое количество одновременно крутящихся на сервере — 1500 одного класса и еще 30 000 второго. примерный обьем данных которые в бинах хранятся 500-600 мб . ND>>Т.е есть путь юзать хранимые процедуры. либо юзать бины. количество пользователей в системе в районе 1500-3000. или ссылочки где про это можно прочитать. и как их производительность увеличить. есть ли Альтернативы.
L>Альтернартивы есть всегда. Особенно в этом случае. Почитать в Expert One-on-One J2EE without EJB. L>Плюс посмотреть на Hibernate.
Спасибо. сейчас буду смотреть. а насчет производительности Entity EJB что скажете?
Здравствуйте, NorthDragon, Вы писали:
ND>Спасибо. сейчас буду смотреть. а насчет производительности Entity EJB что скажете?
Так вот с ними основная проблемма и есть. Это и ограниченность EJBQL, и трудности с импоементацией/деплойментом, оверхеад вызовов методов.
Помимо всего прочего использование Entity EJB начинает диктовать условия дизайну приложения, что совсем не хорошо сказывается на нем (на дизайне), так как приходится не технологию настраивать под нужды а нужды выводить согласно технологии. Вобщем, must die!
Здравствуйте, Lucker, Вы писали:
L>Здравствуйте, NorthDragon, Вы писали:
ND>>Спасибо. сейчас буду смотреть. а насчет производительности Entity EJB что скажете?
L>Так вот с ними основная проблемма и есть. Это и ограниченность EJBQL, и трудности с импоементацией/деплойментом, оверхеад вызовов методов. L>Помимо всего прочего использование Entity EJB начинает диктовать условия дизайну приложения, что совсем не хорошо сказывается на нем (на дизайне), так как приходится не технологию настраивать под нужды а нужды выводить согласно технологии. Вобщем, must die!
получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
Здравствуйте, mselez, Вы писали:
M>Здравствуйте, NorthDragon, Вы писали:
ND>>получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
M>где-то читал, что EJB полезна в 5-10 % случаев , в остальных лучше обойтись более простыми решениями типа Spring + Hibernate
Хотелось бы узнть, что относится к 5-10% а что ко всем остальным... по какому критерию разделяют. и по каким параметрами смотреть надо применять EJB или нет
Здравствуйте, Am_Sasa, Вы писали:
A_S>Здравствуйте, NorthDragon, Вы писали:
ND>>получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
A_S>Боюсь навлечь на себя гнев праведный, но EJB дрова еще те
Здравствуйте, NorthDragon, Вы писали:
ND>Хотелось бы узнть, что относится к 5-10% а что ко всем остальным... по какому критерию разделяют. и по каким параметрами смотреть надо применять EJB или нет
5-10% это приложения где необходима "true distributed" модель и где не требуются сложные выборки данных (и читать как AND). Во всех остальных случаях использование Entity EJB не оправдана. (Может я еще что пропустил?)
[skipped] L>Помимо всего прочего использование Entity EJB начинает диктовать условия дизайну приложения, что совсем не хорошо сказывается на нем (на дизайне), так как приходится не технологию настраивать под нужды а нужды выводить согласно технологии. Вобщем, must die!
А не подскажите где можно почитать в каких случаях применение Entity EJB является лишним, и неумеестным?
И неужели у него нет будущего? Обидно как то, что такая важная часть Java, не будет использоваться "по полной" и будет заменена чем-то вроде Hibernate(я не против, но больше нравиться использовать родные средства)
Может с реализацией 3-й спецификации все наладиться?
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, mselez, Вы писали:
ND>>>получается Entity совсем отстой.... или вся технология EJB по твоему отстой? почему тогда Sun ее поддерживает?
M>>где-то читал, что EJB полезна в 5-10 % случаев , в остальных лучше обойтись более простыми решениями типа Spring + Hibernate
C0s>здесь надо все-таки четко сказать — речь о EJB вообще или об Entity EJB в частности? C0s>т.к. есть задачи, для которых Session EJB являются практически единственным стандартным переносимым подходом. C0s>например, система, доступ к которой производится не только через Web GUI, а также через утилиты командной строки, свинг-клиенты. здесь Session EJB помогает для переносимого решения защиты этой системы от несанкционированного доступа на всех уровнях приложения, т.к. JAAS для всего этого хозяйства довольно неплохо специфицирован. C0s>+ стоит помнить про message-driven beans
Речь идет конкретно о Entity(BMP) bean'ах кол-во бинов одного типа — 30 000 и воторого типа 4000. Если надо какие то по-подробнее данные могу сказать подробнее.
Здравствуйте, andrew_g, Вы писали:
_>А не подскажите где можно почитать в каких случаях применение Entity EJB является лишним, и неумеестным?
http://www.theserverside.com
_>И неужели у него нет будущего? Обидно как то, что такая важная часть Java, не будет использоваться "по полной" и будет заменена чем-то вроде Hibernate(я не против, но больше нравиться использовать родные средства)
Да обидно. А ты сначала попробуй и то и другое. А потом расскажешь как тебе нравяться "родные" средства.
_>Может с реализацией 3-й спецификации все наладиться?
Читый там же. Много топиков на эту тему нужно только поискать.
Здравствуйте, Blazkowicz, Вы писали:
_>>Может с реализацией 3-й спецификации все наладиться?
B>Читый там же. Много топиков на эту тему нужно только поискать.
Может, если учитывать что реализацией 3-й спецификации будет основана на Hibernate3 , и что один из авторов спеки и есть автор Hibernate.
Если честно, на 3 еще даже не смотрел
Здравствуйте, NorthDragon, Вы писали:
ND>Речь идет конкретно о Entity(BMP) bean'ах кол-во бинов одного типа — 30 000 и воторого типа 4000. Если надо какие то по-подробнее данные могу сказать подробнее.
спасибо, не надо я "страшилки на ночь" лучше в художественной литературе/телевизоре поищу
если серьезно, берите hibernate, читайте hibernate_in_action, и, как результат, сделаете качественную работу с вашими объемами хранимых объектов
_>>>Может с реализацией 3-й спецификации все наладиться?
B>>Читый там же. Много топиков на эту тему нужно только поискать.
L>Может, если учитывать что реализацией 3-й спецификации будет основана на Hibernate3 , и что один из авторов спеки и есть автор Hibernate.
L>Если честно, на 3 еще даже не смотрел
ejb 3.0 для CMP бинов — крутая вещь. Hibernate сразу отметается
по теме: еджб не предназначен для bulk процессов (крутые sql действия)
(особенно при BMP бинах)
Здравствуйте, mselez, Вы писали:
M>где-то читал, что EJB полезна в 5-10 % случаев , в остальных лучше обойтись более простыми решениями типа Spring + Hibernate
я немного владею джавой потому что приходиться на делфи писать и поэтому есть пробелы в знаниях
обьясните пожалуйста что такое Spring + Hibernate и почему это лучше EJB в 90-95%
Здравствуйте, NVadim, Вы писали:
NV> ejb 3.0 для CMP бинов — крутая вещь. Hibernate сразу отметается
NV> по теме: еджб не предназначен для bulk процессов (крутые sql действия) NV> (особенно при BMP бинах)
а можно по-подробнее. что относится к крутым запросам. и какие причины малой производительности BMP бинов.
Спасибо за подсказку. ща буду смотреть 3 спецификацию
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Disa, Вы писали:
B>2 frameworkа аналогичные по функциональности EJB, но на порядок быстрее, удобнее и пр...
B>Spring заменяет в основном сессийные бины и многое другое, а Hibernate отличнейшая замена CMP и BMP.
ОЧЕНЬ интересно
а ссылочки у вас не будет для изучение или ознакомления
спасибо за ответ.
Здравствуйте, Disa, Вы писали:
D>Здравствуйте, Blazkowicz, Вы писали:
B>>Здравствуйте, Disa, Вы писали:
B>>2 frameworkа аналогичные по функциональности EJB, но на порядок быстрее, удобнее и пр...
B>>Spring заменяет в основном сессийные бины и многое другое, а Hibernate отличнейшая замена CMP и BMP.
D>ОЧЕНЬ интересно
D>а ссылочки у вас не будет для изучение или ознакомления D>спасибо за ответ.
Здравствуйте, Blazkowicz, Вы писали:
D>>обьясните пожалуйста что такое Spring + Hibernate и почему это лучше EJB в 90-95%
B>2 frameworkа аналогичные по функциональности EJB, но на порядок быстрее, удобнее и пр...
B>Spring заменяет в основном сессийные бины и многое другое, а Hibernate отличнейшая замена CMP и BMP.
насчет аналогии функциональности — а как в Spring сделаны а) декларативный security, б) как там с прозрачной транзакционностью, в) как там насчет прозрачной распределенности?
