Так чтобы дней за 5 постигнуть философию Entity (CMP, BMP, если можно, в связке с hibernate), Session (Stateless, Statefull) и MessageDriven (или как там они) Beans. Можно конечно и яндексом и гуглом, но на отделение зерен от плевел, боюсь, уйдет непозволительно много времени, а нужно начать уже вчера. Вот такая вот засада... Есть у кого что на примете?

Есть конечно.

http://www.theserverside.com/books/wiley/m...ngEJB/index.tss

Больше ничего не надо. Правда плохо то, что там все отвлечено от конкретного контейнера, поэтому последние 5% в каждом примере за тобой Но при усидчивости пробьешь

ух, в какой уже раз выручаешь

И еще с привязкой к контейнеру (JBoss) - The JBoss 4 Application Server Guide. Глава 11 про CMP-бины, глава 13 - про интеграцию с Hibernate. Где-то читал, что в JBoss собираются контейнер CMP сделать на основе Hibernate, но кажется до этого дело еще не дошло.

мля!!! 840 страниц..... Код примеров в архиве - 5.3 метра... Как раз на 5 дней ....

Цитата(Zandr @ 24.5.2005, 00:15)

мля!!! 840 страниц..... Код примеров в архиве - 5.3 метра... Как раз на 5 дней .... smile smile smile smile

Тебе нужно около половины, из них начало - общие рассуждения

Мне вообщем-то понравился тутор на SUN - J2EE

Zandr, а ты уверен, что тебе нужны EJB?

Просто в подавляющем большинстве проектов, построенных на EJB, использование EJB вообще не оправдано. Все приеимущества, которые как бы приносит эта технология, являются на поверку мнимыми и/или за них приходится платить страшную цену в виде кошмаров конфигурирования, отладки, плохой сопровождаемости и пр. Чтобы не быть голословным, назову эти якобы преимущества:

• распределенность
• persistence - не знаю как по-русски
• декларативное управление транзакциями
• декларативное управление доступом

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

Поэтому если ты хочешь просто для себя разобраться в идеологии EJB, то, разумеется, почитай те книжки, которые тебе порекомендовали, но если речь идет о проектировании системы, которую именно тебе предстоит разрабатытвать и сопровождать, то очень советую для начала прочитать книжку Рода Джонсона "J2EE Development Without EJB". Там очень хорошо расписано, почему EJB - это плохо, и для всех сфер их применения предлагаются более "легкие" альтернативные решения.

Скачать можно со страницы, на которую давал ссылку Souljah и Котъ:

http://java.fpestde.net/

Stampede
Не мог бы ты вкратце перечислить альтернативы, если помнишь?

Цитата(Lamer @ 24.5.2005, 21:48)

Не мог бы ты вкратце перечислить альтернативы, если помнишь?

Боюсь, вкратце не очень получится, но я все же постараюсь.

Короче, Род Джонсон - это Java писатель, архитект и активный участник опен-сорс движения. В качестве последнего он возглавляет разработку Spring - легкого (lightweight) контейнера, который на самом деле является более фреймворком, чем контейнером - смотря с какой стороны смотреть.

У него есть уникальное (уникальное больше в своей целостности, потому что сами по себе отдельные идеи как бы не сильно новы) видение архитектуры J2EE приложения, основанное на приличном опыте разработки больших проектов. И вот нахлебавшись горя с EJB, он выносил под сердцем свою собственную концепцию и реализовал ее в виде Spring'а.

При этом он написал две книжки, J2EE Design and Development и J2EE Development without EJB. Первую я видел только в виде оглавления. а вторая лежит у меня на работе, и когда мне хочется отвлечься от грустных мыслей о несовершенстве этого мира, я просто открываю ее и улетаю парить вслед за мыслью автора, до того складно задувает, подлец

Книжки во многом пересекаются, и главная мысль там сквозит примерно такая: Люди, очнитесь, не надо идти за мейнстримом, не надо слепо юзать EJB только потому, что оно существует - и подробнейшим образом аргументирует свою позицию. Я его книжку воспринял всей душой, потому что она удивительно тонко резонирует в такт моим собственным мыслям по этому поводу. Причем моему самомнению льстит то обстоятельство, что я все это видел и осознавал еще года четыре назад, когда по поводу EJB была только одна всеобщая эйфория, причем не имея ни малейшего опыта практической работы с EJB - чисто умозрительно.

Говоря о Спринге: ключевыми словами к пониманию идеологии Спринга являются:

• легковесность
• IoC (inversion od control)
• AOP (aspect-oriented programming)

В понятие легковесности он вкладывает не столько скромность к ресурсам (хотя и это тоже), сколько способность технологии быть non-invasive, то есть оказывать как можно меньшее влияние на архитектуру приложения, быть по возможности прозрачной. Например, EJB - это очень, просто охерительно инвазивная технология. Если ты пошел по пути EJB - все, ты отдал всю свою свободу. Все твое приложение будет состоять из кучи EJB. Как нельзя быть немножко беременной, так и приложение не может быть немножко EJB. Это подход по принципу все или ничего.

Далее, второй ключевой концепт: инверсия управления. Тут речь идет о том, что надо перестать думать о приложении в терминах понятий, навязываемых тебе технологией, а думать о нем как о наборе простых человеческих классов и компонентов, которые наилучшим образом отвечают прикладной области этого приложения - то, что называется POJO (plain old Java objects). Но прикол с POJO заключается в том, что там существует много зависимостей одних компонентов от других, причем подчас бывает довольно трудно уследить, что в каком порядке должно инициализироваться и т. д. В Спринге эта проблема решается посредством механизма, который называется Dependency Injection. Заключается это в том, что ты как разработчик описываешь эти зависимости в файле конфигурации и потом можешь просто об этом забыть - Спринг разрешит все зависимости за тебя.

У меня, честно говоря, смешанные чувства по поводу этого подхода, потому что я очень, просто органически не переношу кодировать в XML. Я лучше десять раз запрограммирую, чем один раз сконфигурирую. Но многим нравится, так что, может, что-то в этом есть.

И третье, AOP. Ну, это для меня совсем новое понятие, я еще не очень понимаю, в чем от него кайф. То есть на пальцах это примерно так: ООП это очень здорово, но бывают моменты, когда ООП не сильно может помочь - это когда нужна служебная функциональность, которая логически идет поперек твоей вертикальной классовой иерархии: например, служба логирования, или контроль доступа, или управление транзакциями.

Тогда ты как-то там это программируешь отдельно, а в нужных местах, где это будет использоваться, вставляешь указание на то, где это должно перехватываться и выполняться. Это может делаться через кодогенерацию. через модификацию байткода на этапе компиляции или, как это сделано в Спринге, на этапе выполнения.

А теперь о тех альтернативах EJB, которые предлагает автор. Тут сразу надо отметить, что будучи активным продвигателем своего Спринга, он все в конечном итоге сводит к Спрингу, хотя реально в нем нет реализаций отдельных служб, а есть только слои абстракции.

1. Персистенция

Предлагается выбор из Hibernate, TopLink или другого O/R средства, или JDO. Во избежание попадания в зависимость от конкретного производителя, рекомендуется пользоваться интьерфесом, предоставляемым Спрингом.

2. Управление транзакциями

JTA, или в простых случаях просто JDBC координация, опять же через слой абстракции Спринга.

3. Удаленность

RMI, SOAP, плюс он очень рекомендует проприетарные протоколы от Caucho: двоичный Hession и хмл'ный Burlap.

4. Пулинг ресурсов

Предлагает внешние библиотеки типа Apache Commons Pool.

5. Управление доступом

Показывает то, до чего мне в свое время пришлось доходить самостоятельно: что JAAS и декларативное управление доступом - это неработающая вещь. Как выход - предлагает реализовывать управление доступом средствами AOP.

6 Синхронизация потоков

То, чего в EJB как бы вообще нет (в смысле как в анекдоте про монгольского космонавта: будешь лезть куда не следует, получишь по рукам). А синхронизировать - бывает надо. Для этой цели можно например использовать широко всеми используемую библиотеку синхронизационных примитивов Дага Ли (Doug Lea).

7. Асинхронная обработка

Вот тут, говорит, звиняйте, братцы - чего нет, того нет. Не придумали пока ничего взамен Message Beans. Хотя, говорит, если сильно невмоготу, можете пока пользовать JMS в чистом виде, а там что-нибудь придумаем.

Вот так вот примерно, если в нескольких словах. Хотя сам я, признаться, Пастернака не чител, в смысле Спринг не юзал - сужу только по книжке

Гут. Спасибо.

Цитата

Короче, Род Джонсон - это Java писатель

Он, конечно, перец крутой и может себе позволить пофантазировать, но нам, простым смертным, этого делать нежелательно.

Что я имею ввиду? Я имею ввиду принцип "20х80", т.е. 20% проектов приносит 80% денег.

А именно: с ejb работают фирмы, которым как раз и нужна масштабируемость и распределенность, а это консалтинговые фирмы типа IBM, банки, телекоммуникации и т.п. Для них 2 -16 млн транзакций в час - норма, а там уже Hibernate не работает. И попробуйте менеджеру из IBM сказать что-то про Hibernate - он отправит вас в отпуск на лечение нервов. А именно в больших конторах и платят программистам, а там, где пишут "интернет-магазины" - слезы вместо з/п.

Если идти дальше с работой в больших конторах, то можно сказать - забудьте вообще про способ реализации работы с БД. Почему? Потому что в большой конторе слой работы с БД находится хрен знает где (в Гон-Конге каком-нибудь) а вы через soap будете передавать запросы и команды, возможно, совсем не в sql.

P.S. Это я злюсь на свою маленькую контору

У меня тоже контора маленькая, но про работу с БД и я уже забыл. Промежуточный слой можно организовывать и без Hibernate.

Chinook Конечно без EJB в серьёзных проетах не обойтись, но это не значит что нужно отказываться от таких вещей как Hibernate, другое дело что в таких фирмах как IBM есть свои реализации подобных вещей.

Какой интересный вопрос я задал, получается...
Просто устраиваюсь на работу, велено знать EJB, hibernate. Решения относительно того, на чем реализовывать проект будут приниматься не мной. По крайней мере в ближайшее время. Так что пока лучше просто хорошо делать своё дело. А за рекомендации спасибо - буду вникать

Это сообщение отредактировал(а) Zandr - 27.5.2005, 08:57