 | Уровень сложности: средний Никлас Чейз, Независимый автор, Backstop Media
15.12.2006 В чём же всё-таки прелесть корпоративных компонентов Java (Enterprise JavaBeans (EJBs)), и почему они так важны для развития платформы Java™2, Enterprise Edition (J2EE)? В этом выпуске колонки "Вероотступника Geronimo", Дэвид Блевинс, соавтор OpenEJB, проливает свет на то, что дают вам EJB и объясняет, как OpenEJB был выбран в качестве реализации EJB для Apache Geronimo.
Вступление
Я собираюсь быть предельно честным. На мой взгляд, использовать EJB совсем не просто. Думать над ними надо гораздо больше, чем многие разработчики думают над своими приложениями; они основываются на интерфейсах, вынуждающих реализовывать множество функций, которые вам, возможно, даже не понадобятся; а поскольку вам нужно запускать их внутри контейнера, то придётся исхитриться, чтобы протестировать их с остальной частью вашего приложения, используя, скажем, JUnit.
И всё же они могут стать краеугольным камнем в развитии J2EE.
Поэтому когда Powers That Be попросили меня посвятить этот выпуск "Вероотступника Geronimo" истории выбора OpenEJB в качестве реализации EJB для Apache Geronimo, я был заинтригован. Может быть, я смогу, наконец, понять, что же хорошего в OpenEJB.
Как OpenEJB стал частью Apache Geronimo
Я созвонился с Дэвидом Блевинсом, который вместе с Ричардом Монсон-Хефелем (Richard Monson-Haefel), 6 лет назад создал OpenEJB, и который также участвовал в создании Geronimo. Я хотел знать, что даёт OpenEJB для Geronimo, и что дают разработчикам сами EJB.
Я начал с того, что спросил его о процессе, благодаря которому OpenEJB или что-либо подобное перерастает в более крупный проект, например, в Geronimo. Дэвид объяснил, что он стоял у истоков Geronimo, когда этот проект существовал на уровне слухов, то есть до его официального запуска. "Так что, я определённо участвовал в этом заговоре под названием Geronimo," пошутил он.
Ага, опять заговор! Я спросил, почему, как он думает, к проекту часто относятся именно так. "О, дело в том, что слово "заговор" выдаёт страх, неуверенность и сомнение тех людей, которые так называют проект". Он объяснил, что первоначальной целью создателей Geronimo было сосредоточиться на подборе "правильных" людей, а уже потом беспокоиться о правильных составляющих. "Всем, кто вовлечён в создание Geronimo, пришлось забыть о себе и о своих программах и полностью посвятить себя проекту", сказал мне Дэвид. По существу, они пытались создать проект с изначально безупречной репутацией.
Так каким же образом OpenEJB стал частью этой репутации? "Ну, я полагаю, благодаря всем, кого вы знаете", сказал Дэвид. Но он не был абсолютно серьёзен. Известно, что всё удалось благодаря Дейну Сандстрому (Dain Sundstrom), одному из первых создателей Geronimo, который пригласил Дэвида участвовать в проекте с самого начала. Фактически, Дейн пытался заполучить Дэвида для участия в похожем проекте разработки программы с открытым кодом около года назад: "Какое-то время он посещал каждое собрание группы Twin Cities Java Users Group (TCJUG) и постоянно докучал мне этим проектом".
Поэтому, когда они всё-таки стали работать вместе, это показалось почти знаком судьбы. Хотя оба были из Миннесоты, в то время, когда зарождался проект Geronimo, Дэвид преподавал в Сан-Франциско. "Я сказал, "Хорошо, я сейчас в Сан-Франциско, поэтому тебе придётся подождать, пока я не вернусь в Миннесоту". И, конечно же, Дейн ответил, "Отлично, я тоже сейчас в Сан-Франциско". Он только что вернулся с конференции. Так, мы встретились в тот же день в Сан-Франциско, чтобы поговорить, и он ожидал снова получить отрицательный ответ, который я ему постоянно давал. Но когда разговор перешёл от работы над тем другим проектом к реализации Apache J2EE, то я сразу же ответил: "Да".
И, будучи лидером OpenEJB (с тех пор как Монсон-Хефель несколько лет назад ушёл), Дэвид вновь сплотил это сообщество вокруг идеи Geronimo. "Мы просто знали, это то, что мы должны делать", сказал он.
Более того, эти две группы, OpenEJB и Geronimo, обнаружили такую сплочённость, которая редко бывает в таких крупномасштабных проектах. Алан Кабрера (Alan Cabrera) со стороны OpenEJB писал систему безопасности для Geronimo, а Аарон Малдер (Aaron Mulder), автор книги о Geronimo, находящейся в свободном онлайновом доступе, существенно переделал консоль, предоставленную IBM®. Дейн Сандстром и Дэвид Дженкс (David Jencks) из группы Geronimo проделали огромную работу для приведения OpenEJB в соответствие с EJB 2.1. (Изначально Open EJB соответствовал только EJB 1.1.) Gianny D'Amour, рано примкнувший к группе Geronimo, разошёлся, разрабатывая то, что Дэвид называет "одним из самых больших патчей к Geronimo или OpenEJB, который я когда-либо видел, в значительной степени завершающий реализацию нашего компонента управления данными CMP [container-managed persistence]." Яцек Ласковски (Jacek Laskowski),долгое время являвшийся выпускающим редактором OpenEJB, начал первые разработки по интеграции Geronimo и Tomcat, завершил которые Джефф Дженендер (Jeff Genender) из Geronimo, который также стал выпускающим редактором OpenEJB.
Инкубатор Apache
Фактически, сказал Дэвид, когда речь идёт об OpenEJB и о Geronimo, "то это, в сущности, одна группа". Это - одна из причин, по которой, когда Geronimo пригласил OpenEJB стать частью Apache, ответ был снова "да".
OpenEJB всё ещё получает необходимую бумаги для того, чтобы стать частью инкубатора Apache -- все сторонние компании, например, обладающие авторскими правами на любую часть программного кода, должны предоставить соответствующие разрешения или оформить дарение в письменной форме. После того, как это будет сделано, код OpenEJB будет иметь свою собственную секцию в Подверсии (Subversion) в инкубаторе. Списки рассылки будут в домене инкубатора и так далее, что сделает процесс более удобным для тех, кто задействован в обоих проектах.
Инкубатор представляется в виде переходного шлюза. Он нужен для проектов, приглашенных стать частью Apache, но формально ещё не принятых. Чтобы успешно выйти из инкубатора, проект должен быть адаптирован к методам, принятым в Apache. "Есть множество критериев", объяснил Дэвид, "но обычно, вы должны продемонстрировать здоровое сообщество и у вас должен быть чистый IP."
Проект в настоящее время работает над так называемым аспектом чистого IP, скупая права у компаний, таких как Intalio, которые финансировали начальный этап разработки. Но здоровое сообщество - это не проблема. Проект находится в действии уже шесть лет и у него есть несколько назначенных выпускающих редакторов. (И эти ряды значительно пополнились благодаря тем, кто пришёл из Geronimo.) Такое многообразие является решающим для Apache. Дэвид объяснил, "Многообразие является решающим аспектом для программного кода и для сообщества, переживающего утечку кадров". Другими словами, когда часть группы уходит на некоторое время, что неизбежно в рамках такого длительного проекта, всему сообществу необходимо быть сильным и достаточно разнородным, чтобы выжить.
Тем не менее, OpenEJB должен выпустить хотя бы один релиз как часть процесса инкубации. На проект уже оказало значительное влияние слияние с Geronimo, особенно это повлияло на контейнер, для которого потребовалось большего всего усилий, чтобы довести его до уровня EJB 2.1.
Две стороны OpenEJB
OpenEJB, фактически, состоит из двух частей: сервера и контейнера, и команда прилагает все усилия, чтобы не смешивать их. В спецификации EJB говорится о контейнере и сервере как о раздельных частях, но нигде не даётся определение этих частей. OpenEJB устанавливает соглашение "контейнер-сервер", и, в конце концов, серверная часть OpenEJB была включена в Geronimo без каких-либо серьёзных изменений, а контейнер был полностью переписан для проекта. "Мы не используем Jetty целиком и не полностью используем OpenEJB, который существовал до создания Geronimo," заметил Дэвид. "Одна из вещей, которой [члены сообщества Geronimo] могут гордиться, состоит в том, что мы не склеивали части в произвольном порядке и не представили всем эдакого Франкенштейна".
Серверная сторона OpenEJB содержит распределённую часть уравнения. В любой распределённой системе должны присутствовать две вещи: способность находить компонент или сервис, которые вы хотите использовать, а также способ их вызова после того, как они найдены. Отыскание компонента или сервиса обычно происходит с использованием какого-либо реестра. В веб-сервисах это -- Universal Description, Discovery and Integration (UDDI). В CORBA это -- CosNaming. В EJB это -- Java Naming и Directory Interface (JNDI). В идеале, вы должны иметь возможность позаботиться о второй части -- о вызове компонентов (будь это веб-сервис, CORBA-процедура, или удалённый EJB) при помощи обычных программных средств. Другими словами, вы должны иметь возможность вызывать компонент, как если бы он был локальным объектом.
Серверная часть среды управляет этим процессом вызова, проверяя, что вызов достигает удалённого объекта, и что ответ возвращается к клиенту. Сервер также управляет такими задачами, как "передача состояния безопасности транзакции между вызовами," сказал Дэвид.
Приходится согласиться, что последовательность для Простых Старых Объектов Java (POJOs) является чрезмерной. Я уже начинаю видеть преимущества использования EJBs. И всё же, я -- человек веб-сервисов, поэтому удалённые системы меня не пугают. Что ещё EJB даёт мне как программисту? Кажется, что многое -- и большая часть из этого сосредоточена вокруг функций, выполняемых контейнером.
Что дают вам EJB
Существуют три типа EJB -- сессионные компоненты (не сохраняющие состояние (stateless) и сохраняющие состояние (stateful)), компоненты, управляемые сообщениями (MDBs) и компоненты управления данными (entity beans). "Мне никогда не нравились термины не сохраняющий состояние или сохраняющий состояние," признал Дэвид, "потому что оба держат состояние. Суть в том, что они имеют различные гарантии этого состояния. Я одно время преподавал EJB [классы], и всегда говорил студентам делить их на выделенные экземпляры и разделяемые экземпляры. Выделенные экземпляры -- это сохраняющие состояние сессионные компоненты, а разделяемые экземпляры -- это не сохраняющие состояние сессионные компоненты. Разделяемый экземпляр -- это как книга, которую вы взяли в библиотеке. Если вы её сдали после прочтения, то вы можете взять эту книгу опять, но физически это может быть другая книга, даже если у неё будет то же самое название. А ведь кто-то мог на ней что-нибудь нацарапать или что-то в ней написать, и вам придётся за это отвечать, если вас спросят".
Выделенные или сохраняющие состояние компоненты не имеют такой проблемы, потому что если вы запросили один из них, он останется вашим. Больше никто не сможет использовать этот экземпляр компонента, поэтому, можете быть уверены, что все пометки принадлежат вам. Риск заключается в том, что можно накопить почти бесконечное количество этих частных состояний на сервере, поэтому вам надо будет найти способ, чтобы вытеснить те, что не используются, на диск. Всё это управляется контейнером.
Контейнер также управляет MDB, которые позволяют вам легко пользоваться Службой Передачи Сообщений Java (JMS) для отправки сообщений. "Вы можете вызвать [компоненты, управляемые сообщениями] транзакционно, через JMS, которая является очень удобной функцией", объяснил Дэвид. "Вам не придётся писать большую программу. Всё, что вам придётся сделать - это реализовать интерфейс, и запросы будут приходить к вам от JMS." В таком приложении вам нет необходимости сильно беспокоиться о том, что за клиент получит ваши сообщения.
И, наконец, компоненты управления данными, у которых есть свои преимущества, а именно -- постоянное хранение и кэширование. Например, вы можете вытащить информацию из базы данных и воспользоваться компонентом управления данными для того, чтобы кэшировать данные на протяжении транзакции. "Это своего рода оптимизация, которую вам трудно было бы написать самим без ошибок" сказал Дэвид.
Контейнер OpenEJB
За всю эту функциональность отвечает контейнер. Контейнер "управляет пулами не сохраняющих состояние компонентов и кэшами сохраняющих состояние компонентов, а также компонентов управления данными", сказал мне Дэвид, " и когда приходит вызов, он осуществляет всё необходимое, чтобы подготовить компонент для вызова. Он подготавливает любое транзакционное состояние или гарантирует любые требования безопасности до вызова, и потом когда происходит вызов, контейнер имеет дело с любыми сбоями, откатывая транзакции, что-то вроде того, а затем посылает обратно запрос серверу для сообщения клиенту".
Теперь контейнеру надо делать чрезвычайно много. И всё самому. Возможно, стоит использовать компоненты, а не пытаться самому управлять всем этим. Но это далеко не всё, что делает контейнер. Ещё он управляет жизненным циклом каждого компонента.
Вы можете спросить, "Ну и что это значит?" Это значит, что контейнер точно знает, что происходит с компонентом и может сообщить вам об этом. Например, вы хотели бы знать заранее, когда он собирается вызвать компонент, когда начинает транзакцию внутри компонента, когда он заканчивает транзакцию, или когда он разрушает компонент и так далее. Зачем вам это знать? Ну, потому что вы, фактически, могли бы совершить какое-либо действие в этот момент. Например, вы можете реализовать обратный вызов, который, допустим, отсылает сообщение о завершении транзакции или об её откате. Это даёт вам полный контроль над жизненным циклом вашего компонента.
Цена возможностей
Тем не менее, за эти широкие возможности надо платить. Плата заключается в том, что вам придётся реализовывать все эти обратные вызовы, хотите ли вы их использовать или нет. Это может стать проблемой для программистов, которые не нуждаются во всём том функционале, который предоставляет EJB, потому что требование реализовывать каждый обратный вызов не зависит от выбора реализации EJB, а, скорее всего, является следствием того, что EJB реализуются через простые старые интерфейсы Java. "API становится чересчур обременительным для использования в разработке, если ваши потребности соответствуют начальному уровню," сказал Дэвид.
К счастью, большая часть этих сложностей исчезнет с появлением EJB 3.0, который является основным изменением в том, как конструируются EJB. Вместо того чтобы реализовывать интерфейсы или обратные вызовы, вы просто аннотируете свой простой старый класс Java. "В EJB 3.0, вы можете просто сказать "Это -- компонент, который я отнёс к не сохраняющим состояние"", прокомментировал Дэвид. Для реализации обратных вызовов, вы просто создаёте метод и аннотируете его надлежащим образом. "Это требует гораздо меньше усилий с вашей стороны, и эти антишаблоны, которые люди изначально придумали для EJB, использующих сессионные локаторы, и вся эта ерунда с типами, чтобы они могли в основном распространять EJB API -- всё это теперь не нужно".
Конечно, это на будущее, когда (и, я думаю, если) ветка OpenEJB, начавшаяся в первых числах года, станет частью Geronimo. Но даже сейчас есть неоспоримые объяснения, почему OpenEJB так хорошо подходит к серверу приложений.
Отбор и выбор
Как вы, наверное, знаете, Geronimo основан на концепте GBeans, что позволяет вам как администратору точно определять, какие компоненты вы хотите активировать. Так, вы можете иметь супермодернизированную версию или версию с промышленной супер-мощностью, но что вы хотите поддерживать, решать вам. OpenEJB хорошо согласуется с этим концептом, потому что чистое разделение между сервером и контейнером позволяет ему быть гибким, определяя, какой транспорт поддерживать. Например, в то время как некоторые системы EJB требуют наличия CORBA, веб-сервисов и любых других транспортов, которые хочет предложить сервер, OpenEJB даёт вам возможность отобрать и выбрать за счёт представления каждого транспорта в виде GBean. При этом вы можете иметь 2 различных сферы CORBA, любое количество реализаций веб-сервисов и всё, что угодно и что вы считаете необходимым. Или, наоборот, вы можете не поддерживать ничего из этого и разрешить только локальные вызовы. Также, благодаря тому, как сконструирован сервер, вы можете поддерживать множественные транспорты без того, чтобы иметь многочисленные копии сервера приложений или даже приложения.(Примечание автора: Дэвид отмечает, что эта способность особенно полезна для веб-сервисов, где стремятся к полному взаимодействию, но действительная цель -- гораздо уже.)
 |
Что нас ждёт впереди
Забегая вперёд, можно сказать, что у OpenEJB есть некоторые захватывающие возможности в далеком будущем; некоторые -- совершенно новые, некоторые -- не очень. Например, Дэвид очень взволнованно рассказывает о предполагаемом возвращении встроенной возможности для тестирования, управляемого контейнером. Это способность легко тестировать компоненты OpenEJB, используя JUnit. В норме эти компоненты не запускаются без контейнера, требуя от вас установки перед тестированием и удаления после. Но встроенная способность тестирования позволяет вам создать среду, которая включает контейнер, как встроенную часть системы, так же как вы можете встроить базу данных, такую как IBM Cloudscape™. "Так было в OpenEJB 1, в OpenEJB 2 это отсутствовало, и мы надеемся вернуть это в OpenEJB 3," объяснил Дэвид. "Так что, если вы пишете компоненты OpenEJB, вы можете запускать их при помощи обычных тестов JUnit, не суетясь и не нервничая."
OpenEJB 3 будет также поддерживать Java Persistence Architecture API (JPA). Дэвид рассказал, что "OpenEJB исторически предпочитал использовать другие компоненты для постоянного хранения. В OpenEJB 1 мы использовали Castor, во второй версии использовали TranQL. В OpenEJB 3 мы собираемся использовать OpenJPA, и этот API теперь является стандартным, поэтому он будет подключаемым. Так что, если TranQL или Castor или любой другой проект всё-таки решит поддержать JPA, мы будем способны поддержать любой из них или всех их одновременно."
OpenEJB будет также поддерживать внедрение конструктора, который позволит контейнеру предоставлять различные классы и объекты во время работы. Спецификация EJB 3.0 говорит о внедрении общих полей и о внедрении установщика, но внедрение конструктора позволит вам избежать создания установщиков для значений, которые, как вы ожидаете, не изменятся. И, конечно, это поможет избежать необходимости создания той же функциональности, используя общие поля. "В общем как раз то, что мы прекратили делать в 1995, примерно через три дня после того, как была придумана Java," заявил Дэвид.
Резюме
Принимая во внимание постоянное хранение, управление транзакциями и знание того, что программирование с этим API не будет всегда таким болезненным, я могу видеть, в чём значение дальнейших разработок EJB, особенно для проектов, обречённых работать на Apache Geronimo. Эти компоненты являются мощной силой в веб-приложениях и, фактически, даже не в веб-приложениях. Посмотрите раздел Ресурсы в данной статье, там вы найдёте ссылки, которые помогут вам продолжить самостоятельное исследование.
Ресурсы Научиться
- Оригинал статьи: "OpenEJB and Apache Geronimo's EJB implementation"
- Прочитайте больше об Инкубаторе Apache.
-
Присоединитесь к списку рассылок на Веб-сайте Apache Geronimo.
- Прочитайте информацию об использовании OpenEJB и XDoclet для развёртывания дескрипторов "Разверните J2EE приложение на Apache Geronimo" (developerWorks, январь 2006 г.)
- Прочитайте статью Нила Санче (Neal Sanche) "Погрузитесь в EJB веб-приложения вместе с Geronimo (developerWorks, июль 2005 г. г.)
- Просмотрите "Создание, развёртывание и отладка приложений Apache Geronimo" (developerWorks, май 2005 г.) чтобы узнать, как использовать Eclipse для развёртывания вашего приложения на удалённом экземпляре Geronimo.
- Прочитайте "Создавая лучший J2EE-сервер, используем открытый исходный код" (developerWorks, май 2005 г.), чтобы получить информацию о других развивающихся процессах, кроме Geronimo, включая его JSR 88 поддержку.
- Обратитесь к серии из 2 частей на developerWorks, чтобы узнать о поддержке Geronimo для полной спецификации J2EE 1.4: "Geronimo! Часть 1: Механизм J2EE 1.4, который смог бы" и "Geronimo! Часть 2: Укротите дикую лошадь J2EE 1.4."
- Прочитайте Спецификацию JSR 88.
- Просмотрите "Понимание архитектуры развёртывания Geronimo," В статье предлагается подробное описание планов развёртывания Geronimo и то, как Geronimo их использует.
- Получите информацию из этой статьи о том, как соединять вашу базу данных с веб-приложением, написанным для Geronimo (developerWorks, июнь 2005 г.).
- Внимательно прочитайте руководство, "Apache Geronimo uncovered " (developerWorks, август 2005 г.), чтобы выяснить все входы и выходы Geronimo и сравнить его особенности и возможности с WebSphere®Application Server Community Edition.
- Посетите "Зону открытого кода" на сайте developerWorks для получения дополнительной информации "как сделать...", инструментария и обновлений к проектам, которые помогут вам разрабатывать в технологии открытого кода и использовать её с продуктами компании IBM.
- Загляните на developerWorks в раздел проекта Apache Geronimo и прочитайте там статьи, руководства; там же вы найдёте ресурсы, которые помогут вам начать разработки на Geronimo уже сегодня.
- Получите техническую поддержку экспертов в рамках программы IBM Support for Apache Geronimo.
- Найдите полезные ресурсы для начинающих и опытных пользователей в разделе Начните с Apache Geronimo уже сегодняна сайте developerWorks.
- просмотрите все статьи про Apache и бесплатные руководства по Apache, доступные в "зоне открытого кода" на developerWorks.
- Поищите книги на эти и другие технические темы в Интернет-магазине Safari bookstore.
Получить продукты и технологии
Обсудить
Об авторе | | | Никлас Чейз (Nicholas Chase) участвовал в разработке Web-сайтов для таких компаний, как Lucent Technologies, Sun Microsystems, Oracle и Tampa Bay Buccaneers. Ник успел побывать школьным учителем физики, редактором электронного научно-фантастического журнала, инженером в области мультимедиа, инструктором по Oracle и главным инженером в интерактивной коммуникационной компании. Он является автором нескольких книг, в том числе XML Primer Plus (Sams). |
Выскажите мнение об этой странице
| |
