16+
ComputerPrice
НА ГЛАВНУЮ СТАТЬИ НОВОСТИ О НАС




Яндекс цитирования


Версия для печати

Модуль поиска не установлен.

Enterprise JavaBeans - компоненты для сервера

02.09.2003

Антон Тульчинский, <antontul@rambler.ru>


Введение

Технология Enterprise JavaBeans (EJB) является высокоуровневым подходом к построению распределенных систем. Такие фирмы, как Oracle, Borland, Symantec, Sybase, в числе множества других объявили и выпустили продукты, соответствующие спецификации EJB. Эта технология предоставляет разработчику возможность полностью сконцентрировать своё внимание на программировании логики, вместо того чтобы корпеть над кодом обработки транзактного поведения, сведения связей или обработки нитей и т.п. Данная архитектура предполагает, что это теперь должно входить в обязанности производителя сервера.

Между технологиями Enterprise JavaBeans и JavaBeans существует определенная связь (что подчеркивает название), но, в принципе, это - разные вещи. Компоненты JavaBeans используются практически так же, как компоненты Microsoft ActiveX (обеспечение понятных пользователю средств управления для построения пользовательских интерфейсов), в то время как компоненты EJB применяются для реализации транзактного обеспечения и являются невизуальными. Кроме того, EJB не имеет таких вещей, как классы BeanInfo, редакторы свойств или средства настройки. Далее в данной статье мы рассмотрим сравнительные характеристики обеих технологий.

EJB - это модель серверных компонентов (server component model) для Java и одновременно спецификация для создания больших масштабируемых транзактных приложений для промышленных серверов, обеспечивающих высокий уровень защиты данных. Кроме того, компоненты EJB могут внедряться в уже существующие системы обработки транзакций, на Web-серверах, серверах приложений и т.д.

Потребность в EJB

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

Далее будут коротко описаны преимущества работы с EJB для построения программных решений.

EJB занимается управлением транзакциями - производитель контейнера EJB обязан обеспечить функцию управления транзакциями. А разработчику, занимающемуся рабочей функциональностью, нужно беспокоиться только о том, чтобы транзакция началась и закончилась. Кроме того, EJB обеспечивают распределённый характер транзакций - EJB обеспечивают прозрачность распределённых транзакций, что означает, что клиент может начать транзакцию и затем вызвать для выполнения компонентов EJB методы, находящиеся на двух разных серверах, работающих на двух разных машинах, платформах или виртуальных машинах (JVM). Методы одного компонента могут обращаться к методам другого компонента, гарантируя при этом выполнение в одном и том же транзактном контексте.

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

EJB легко интегрируются с CORBA- EJB и CORBA, естественным образом дополняют друг друга. Например, компоненты могут представлять CORBA/IIOP для обеспечения надёжного механизма передачи, или простые клиенты CORBA могут обращаться к компонентам EJB как клиенты EJB. В настоящее время широкий спектр функций может предложить разработчикам CORBAServices производства компании OMG. В будущем производители серверов EJB, возможно, смогут просто заворачивать эти функции в упрощённые API, чтобы ими могли пользоваться разработчики EJB без необходимости быть знатоками CORBA.

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

EJB предоставляет разработчику свободу в ыборе архитектуры - EJB изолирует разработчика от деталей работы программного обеспечения, предоставляя ему возможность видеть только среду Java. Это также позволяет производителю сервера/контейнера делать впоследствии изменения и усовершенствования программного обеспечения, никак не влияя на работу имеющихся у пользователя приложений. EJB помогает создавать переносимые и масштабируемые решения - компоненты EJB, подчиняющиеся требованиям EJB API, устанавливаются, выполняются и переносятся на любой сервер EJB.

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

Жизненный цикл EJB

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

Для облегчения промышленной разработки спецификация EJB определяет обязательства или роли. Спецификация EJB также определяет, кто ответственен за доставку того, что eсть в приложении, которое использует EJB, как показано на рисунке << Жизненный цикл EJB >>.

Спецификация EJB не обязательно препятствует одному и тому же человеку в исполнении более чем одной роли.

Провайдер сервера EJB

Провайдер сервера EJB обеспечивает организованную среду выполнения, в которой действуют контейнеры EJB. Производитель сервера EJB выполняет и обеспечивает доступ к службе имен, совместимой с JNDI и службе транзакций, которая совместима с CORBA-OTS. Обратите внимание, что производитель сервера EJB может также выступать в качестве производителя контейнера EJB.

Провайдер контейнера EJB

Провайдер контейнера EJB предоставляет программное обеспечение для инсталляции EJB с поддерживающими классами на сервере EJB. Производитель контейнера также отвечает за предоставление классов времени выполнения, которые обеспечивают необходимые сервисы для экземпляров EJB.

Они включают генерацию stub- и skeleton-классов для предоставления доступа к home-объекту требования EJB и EJBObject, установление ссылок к home-объекту в пространстве имен, доступном JNDI.

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

Разработчик EJB

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

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

Специалист по внедрению/установке EJB

Хотя специалист по внедрению EJB не обязан быть разработчиком Java или понимать бизнес-правила, которые реализует класс EJB, он должен понимать среду приложения, в которой запускается экземпляр EJB. Дополнительно, специалист по внедрению должен всестороннее понимать характеристики оперативных средств сервера, таких как типы базы данных, ее расположение и так далее.

Специалист по внедрению ответственен за определение EJB и всех их поддерживающих классов и их правильную инсталляцию на сервере EJB.

Специалист по внедрению получает требования класса EJB от разработчика EJB, такие как потребности транзакций, имена, описание необходимых параметров среды, и так далее. Специалист по внедрению ответственен за обеспечение доступности таких параметров (вместе с их корректными значениями) классу EJB во время исполнения.

Специалист по внедрению также должен обеспечивать доступность home-объекта для класса EJB в пространстве имен и посредством JNDI. Специалист по внедрению и разработчик должны четко общаться, чтобы быть уверенными в том, что класс EJB внедряется с правильными атрибутами установки.

Разработчик приложения

Разработчик приложения пишет клиентские приложения, используя заготовки компонентов EJB. Здесь клиент определяется в общих чертах и может быть приложением Java, апплетом, сервлетом, приложением CORBA или даже элементом управления ActiveX, соединяющимся посредством моста COM-CORBA.

Разработчик приложения может таким образом подключить готовые EJB без необходимости их разработки или тестирования, или без наличия каких-либо определенных знаний, как их интегрировать.

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

Типы Enterprise JavaBeans

Есть два основных типа Enterprise JavaBeans: session beans и entity beans. Эти два типа играют разные роли в распределенном EJB-приложении.

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

В частности, session-объекты обычно не переживают сбоев сервера. Примером session-объекта может быть EJB, который живет на Web-сервере, предоставляющем пользователю HTML-страницы, и отслеживает перемещения пользователя по сайту. Когда пользователь покидает сайт или по истечении указанного времени ожидания, session-объект будет уничтожен.

Заметьте, что хотя этот session-объект и может сохранять информацию в БД, его назначение не в создании или обновлении содержания БД, он соответствует одному клиенту, производящему некие действия с серверными EJB.

Сущностные, или entity bean, предоставляют пользователю информацию, обычно хранящуюся в БД. Entity beans ассоциированы с транзакциями БД и могут предоставлять доступ к данным множеству пользователей. Поскольку данные, представляемые ими, существуют постоянно, entity beans переживают сбои сервера (после перезагрузки сервер воссоздаст bean по имеющимся данным.)

В реляционных терминах, entity bean должен представлять строку нижележащей БД или единичную строку результата SELECT. В объектно-ориентированной БД (OODB) entity bean может представлять единичный объект с его ассоциированными атрибутами и связями.

Примером entity bean может служить объект Employee для конкретного работника в БД персонала компании.

Session beans управляют информацией, относящейся к взаимодействию клиента и сервера, а entity beans представляют и манипулируют данными приложения. Каждый EJB имеет уникальный идентификатор.

В случае entity beans этот уникальный идентификатор гарантирует идентичность информации. Например, EmployeeIDNumber может уникально идентифицировать объект Employee. Это аналог концепции первичного ключа в реляционных системах БД.

Уникальный идентификатор session bean хоть как-то отличает его от других аналогичных beans: это может быть имя хоста и номер порта удаленного соединения или даже случайно сгенерированный ключ, используемый клиентом для уникальной идентификации данного "боба".

Базовая модель EJB

Базовая структура EJB показана на рисунке << Базовая структура EJB >> и состоит из:

- Cервера EJB

- Контейнеров EJB, которые работают внутри сервера

- Home-объектов, remote-объектов EJBObjects, и EJB, которые работают в контейнерах

- Клиентов EJB

- Вспомогательных систем, таких как JNDI, JTS, систем безопасности, и так далее.

Сервер EJB

Сервер EJB обеспечивает организованную структуру или среду для выполнения, в которой могут работать контейнеры EJB. Он предоставляет системные сервисы для мультипроцессорной обработки, выравнивания нагрузки и доступа устройств для контейнеров EJB. Сервер EJB также делает EJB-контейнеры видимыми для внешнего мира. Он также может предоставлять свойства, зависящие от поставщика, такие как интерфейс оптимального доступа к данным, дополнительный CORBAServices, SSL-поддержку, JNDI-доступную службу имен и службу управления транзакциями. В некотором отношении, сервер EJB является аналогом CORBA's Object Transaction Monitor (OTM). OTM также обеспечивает среду для выполнения действий серверных компонентов CORBA.

Контейенеры EJB

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

Объекты и интерфейсы EJB

Методы для нахождения, создания и удаления экземпляров классов EJB определяются в home-интерфейсе. Home-объект является реализацией home-интерфейса. Разработчик EJB сначала должен определить home-интерфейс для своего бина. Производитель контейнера EJB предоставляет средства, которые автоматически генерируют код-реализацию для home-интерфейса, определенного разработчиком EJB.

Remote-интерфейс перечисляет бизнес-методы, доступные для EJB. EJBObject является клиентским представлением EJB и реализовывает remote-интерфейс. В то время как разработчик EJB определяет remote-интерфейс, производитель контейнера предоставляет средства, необходимые для генерации кода для соответствующего EJBObject.

Каждый раз, когда клиент вызывает методы EJBObject, контейнер EJB сначала обрабатывает запрос перед тем, как отправить его EJB.

EJB

Настоящий EJB содержится сам по себе в контейнере EJB и никогда не должен быть напрямую доступен никому кроме контейнера. Хотя прямой доступ может быть возможен, это не рекомендуется, так как разрывает связь (контракт) между бином и контейнером. Контейнер EJB должен служить связующим звеном между всеми доступами к EJB. По этой причине разработчик EJB не реализует remote-интерфейс в самом EJB.

Код для remote-интерфейса генерируется автоматически средствами, предоставляемыми производителем контейнера, в форме EJBObject. Это предотвращает от случайного прямого доступа клиентов или других бинов.

Клиенты EJB

Клиенты EJB находят определенный контейнер EJB, который содержит EJB через Java Naming and Directory Interface (JNDI) (Java-интерфейс именования и каталогов). Затем они используют контейнер EJB для вызовов методов бина. Клиент EJB только получает ссылку на экземпляр EJBObject и никогда в действительности не получает ссылку на текущий экземпляр собственно EJB. Когда клиент вызвает метод, экземпляр EJBObject принимает запрос и перенаправляет его соответствующему экземпляру бина, предоставляя всю необходимую дополнительную функциональность.

Клиент использует home-объект для нахождения, создания или разрушения экземпляров EJB. Затем он использует экземпляр EJBObject для вызова бизнес-методов экземпляра бина.

Продукты поддержки: серверы, приложения

Многие компании поддержали технологию Enterprise JavaBeans. Большинство крупных производителей - куда входят компании IBM, Oracle, Sybase, Netscape и BEA Systems- приняли участие в разработке спецификации Enterprise JavaBeans. Они реализуют поддержку технологии Enterprise JavaBeans в своих продуктах.

Первые серверы, совместимые с EJB-приложениями, начали появляться в 1998 году. Продукты, которые поставляются в настоящее время, включают:

- BEA WebLogic Tengah

- Bluestone Sapphire/Web

- GemStone GemStone/J

- IBM WebSphere Advanced Edition

- Novera jBusiness

- Oracle8i / Oracle9i

- Oracle Application Server

- OrchidSoft Vanda

- Persistence PowerTier

- Progress Apptivity

- Secant Extreme

- Valto Ejipt

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

Некоторые совместимые с EJB приложения и компоненты:

- Athena Design Integer (электронная таблица для деловых операций)

- Digital Harbor personal productivity application components

- EC-Cubed electronic commerce components

- IBI EDA components (обеспечить интеграцию с серверными данными и приложениями)

- IBM San Francisco Frameworks (General Ledger, Order Management, etc.)

- NovaSoft Novation (электронная система ведения документации)

- Oracle Applications (ERP)

- Seven Mountains personal productivity application components

- TradeEx procurement components

Первейшим тормозом на пути развития технологии Enterprise JavaBeans стала компания Microsoft. Хотя Microsoft Transaction Server (MTS) можно было бы приспособить к тому, чтобы он поддерживал компоненты Enterprise JavaBeans, однако компания Microsoft вряд ли пойдёт на это.

Возможности переносимости Java подрывают позиции компании Microsoft в области тесной интеграции на базе платформы NT. Компания Microsoft вынуждает разработчиков строить программные системы, основанные на компонентной модели COM. MTS предоставляет контейнерные системы для серверных компонентов COM, а также сервисы транзакций и защиты, подобные тем, которые обеспечивают серверы Enterprise JavaBeans.

Модель COM+, следующее поколение MTS, будет предоставлять некоторые дополнительные возможности, такие как динамический баланс загрузки и обработка очередности запросов.

Достоинства EJB

Обычно выделяют следующие достоинства архитектуры Enterprise JavaBeans

Масштабируемость и универсальность

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

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

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

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

Независимость архитектуры

Архитектура Enterprise JavaBeans абсолютно независима от какой бы то ни было конкретной платформенной инфраструктуры, протоколов или микропрограммных средств. Приложения, разрабатываемые для одной платформы, перебрасываются или переустанавливаются на другой платформе.

Приложения EJB способны масштабироваться от простой среды Novell на базе одного процессора Intel до крупной многопроцессорной среды на базе UltraSPARC, вплоть до среды больших промышленных мэйнфреймов Sysplex IBM без каких-либо дополнительных модификаций.

Совместимость

Архитектура Enterprise JavaBeans оказалась чрезвычайно совместимой эволюционной средой. Функции Enterprise Java накладываются на функции других инфраструктур.

Компаниям не требуется применять дополнительные микропрограммные технологии. Enterprise JavaBeans поддерживает и упрощает такие популярные системы, как CORBA и DCOM.

Переносимость компонентов

Архитектура Enterprise JavaBeans предлагает простую изящную модель контейнера для серверных компонентов.

Эта модель гарантирует, что серверные компоненты Java-платформы могут разрабатываться один раз и применяться везде, в контейнере любого производителя.

Даже несмотря на тот факт, что системы контейнеров реализуют свои исполнительные функции по-разному, интерфейсы Enterprise JavaBeans гарантируют, что любой enterprise bean может работать в любой системе, что обеспечивает устойчивый жизненный цикл, устойчивость неизменных данных, транзакций, распределённости и защищённости.

Эффективность разработки

Архитектура Enterprise JavaBeans способствует повышению производительности разработчиков приложений. Среда Enterprise JavaBeans автоматизирует процесс использования сервисов сложных инфраструктур, типа транзакций, управления нитями и средствами защиты.

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



статьи
статьи
 / 
новости
новости
 / 
контакты
контакты