Концепция ejb-компонентов
EJB пошла по пути создания ограниченной, но в то же время достаточно гибкой компонентной модели. Ее достоинством является простота автоматизации создания компонентов и управления ими. Концептуально можно выделить два вида компонентов EJB:
компоненты, ориентированные на взаимодействие сервера и конкретного пользователя. Такая ориентированность означает, что компонент создается клиентом в начале сеанса работы с сервером и прекращает свое существование при завершении этого сеанса - отсюда и их название - session-компоненты. Поскольку session-компонент обслуживает только конкретного клиента, технология не предусматривает для него команды «поиска» - вполне достаточно команды «создания». Эти компоненты, в свою очередь, также можно разделить на две группы - компоненты с состоянием, которые отслеживают историю своих вызовов клиентом, и компоненты без состояния. Такие два подвида введены для оптимизации управления их циклом жизни, и их отличия не так уж важны для прикладного программиста. Заметим, что session-компоненты без состояния являются основой для создания COM+ -приложений.
компоненты, являющиеся объектным представлением данных в БД - реляционных или объектных. Они называются Entity-компонентами. Создание entity-компонента связано с добавлением данных в базу данных, его уничтожение - с удалением, например, записи их таблицы реляционной базы данных. В принципе, интерфейс пользователя entity-компонентов может даже не содержать команды «создать» - компоненты создаются автоматически, например, в результате выполнения SQL-команды INSERT, зато обязательно должна присутствовать команда (или команды) «найти». Поскольку entity-компонент предназначен для доступа к информации, доступной многим клиентам, он не может содержать информацию, специфическую для одного клиента. Его состояние - просто кешированная копия информации из (записи) базы данных.
Обычно в EJB-приложении клиент «общается» с информацией в базе данных по цепочке «клиент - session-компонент - entity-компонент(ы)».
Как видите, компонентная модель EJB обеспечивает, в общем, все теоретически необходимые виды компонентов. Ограниченность этой модели по сравнению, например, с универсальной моделью CORBA, состоит не в отсутствии каких-то компонентов, а в ограничениях на правила манипулирования ими. Например, не предусмотрено создание и доступ к компоненту, разделяющему информацию о сеансах работы нескольких клиентов - разделяемая информация в общем случае должна находиться в базе данных.
Какие проблемы решаются с помощью ejb
Если сформулировать в самой краткой форме преимущества, которые получает компания, использующая EJB для создания корпоративных систем, то, наверное, получилось бы следующее: отпадает необходимость иметь в штате (или привлекать к работам в рамках проекта) квалифицированных специалистов в системных областях. Вместо этого фирма платит деньги и получает готовые решения по обеспечению взаимодействия EJB-компонентов, реализующих необходимую функциональность, и операционной среды. Разработчик проекта может не беспокоиться о возможных проблемах с точки зрения функционирования системы на разных платформах, в разных операционных системах и при взаимодействии с различными СУБД, поддерживающими технологию JDBC. EJB демонстрирует высокую эффективность и уровень масштабируемости создаваемых приложений. Кроме того, системы получаются открытыми в том смысле, что с ними могут взаимодействовать CORBA-клиенты, написанные на любом из языков, поддерживающих CORBA.
При использовании EJB cнижаются (по сравнению с традиционными подходами) требования к квалификации основной массы программистов, зато очень важно иметь грамотных менеджеров проекта.
Следует иметь в виду, что требуется предварительный анализ, насколько технология EJB оптимальна для решения именно вашей задачи.
EJB, RMI и CORBA
Ранее говорилось о конкуренции нескольких технологий в рамках создания серверных приложений, и при этом упоминалась технология CORBA. На самом деле говорить о CORBA исключительно как о сопернике технологии EJB, конечно, не приходится. Многие CORBA-средства сознательно положены разработчиками EJB в фундамент этой технологии. В первую очередь, это протокол обмена IIOP и Служба Управления Транзакциями (в EJB используется отображение на Java Объектного Сервиса Транзакций, OTS, CORBA). Кроме того, на использовании инфраструктуры и возможностей CORBA часто основаны многие сервисы EJB - например, служба имен JNDI, которая в реализации технологии EJB фирмой Inprise (Inprise Application server 4.0) работает «поверх» Службы Именования (Naming Service) CORBA.
Существует стандарт отображения EJB на CORBA, касающийся управления транзакциями, безопасностью и службы имен. В этом стандарте указано, что спецификация EJB 1.1 не требует (хотя и считает желательной) полную координацию между EJB и CORBA; жесткое требование в этом плане содержится в спецификации Java 2 Enterprise Edition (J2EE).
Итак, составной частью EJB может быть только то, что соответствует стандартам как RMI, так и CORBA. Такое подмножество обычно называют RMI/IDL.
Такое взаимодействие не означает, что EJB и CORBA постепенно мигрируют в сторону создания некой единой технологии. Между ними остаются фундаментальные различия. EJB является сравнительно небольшой моделью, оптимизированной для решения вполне конкретных классов задач с использованием небольшого количества стандартных подходов, к тому же базирующейся исключительно на языке Java. CORBA возлагает на свою объектную модель надежды, связанные с созданием универсального подхода к решению всех проблем, связанных с взаимодействием удаленных объектов, и с этой точки зрения EJB может рассматриваться как некий частный случай - например, как результат отображения некоторого подмножества универсальной CORBA-модели на язык Java. Планы OMG, как видите, не страдают отсутствием амбиций, но даже если эти планы и будут полностью реализованы, то это произойдет не завтра. Программисты же, которые нуждаются в средствах создания качественных корпоративных приложений, хотят иметь их уже сейчас.
Enterprise JavaBeans по названию похожа на другую Java-технологию – JavaBeans, что может создать впечатление, что одно является развитием другой. Конечно, некий элемент преемственности присутствует; и та, и другая технологии предлагают компонентную модель и основаны на использовании Java. На самом же деле правильнее будет считать JB и EJB различными технологиями.
Компонентная модель EJB ориентирована на создание эффективных серверов приложений. Поскольку сервера приложений, как правило, не рассчитаны на работу в интерактивном режиме и часто вообще не требует наличия оператора, то задачи, решаемые с помощью EJB, в корне отличаются от задач, где разумно и удобно использовать JB. EJB - это модель создания и управления серверными объектами, оптимального использования ресурсов серверов, управления правами доступа и безопасностью, управления транзакциями и взаимодействия с базами данных различных видов.
Естественно, что технология создания серверных объектов, базирующаяся на Java, использует технологию RMI для организации удаленных вызовов между виртуальными машинами Java. Правда, собственно RMI не предоставляет никаких универсальных путей управления транзакциями, да и служба имен RMI недостаточно развита по сравнению, например, со своим CORBA-аналогом. Поэтому разработчики EJB приняли решение использовать сильные стороны как одной, так и другой технологии - и RMI, и CORBA.
Разработчику компонентов нет необходимости использовать язык OMG IDL для определения удаленных интерфейсов - можно использовать стандартную семантику Java RMI. Если необходимо, на базе этих Java-объявлений с помощью стандартного компилятора, разработанного OMG (rmi2idl), можно сгенерировать IDL-файл, который может быть использован CORBA-программистами для создания на любом поддерживающем CORBA языке клиентских приложений, взаимодействующих с EJB как серверными объектами CORBA. Подчеркнем это еще раз: любой компонент EJB является одновременно полноценным CORBA-объектом.
Интерфейс Java, соответствующий спецификации RMI/IDL, должен соответствовать следующим требованиям:
этот интерфейс явно или неявно должен наследовать интерфейс java.rmi.Remote;
все его базовые интерфейсы соответствуют требованиям RMI/IDL;
все методы интерфейса должны возбуждать исключение java.rmi.RemoteException;
все аргументы методов и возвращаемые типы должны соответствовать требованиям RMI/IDL, предъявляемым к типам. Тип считается соответствующим требованиям RMI/IDL, если он либо один из базовых типов языка Java, либо это ссылка на удаленный объект, либо это любой класс Java, реализующий (явно или неявно) интерфейс java.io.Serializable, либо это массив всех ранее перечисленных типов, либо это исключение, либо это тип java.lang.Object.
Такие требования не накладывают почти никаких ограничений по сравнению с обычными правилами RMI. Обратите внимание, что в связи с особенностями IDL нельзя использовать в одном удаленном интерфейсе одно и то же имя для нескольких методов. При генерации IDL-деклараций на базе RMI-интерфейсов, содержащих несколько методов с одинаковыми именами (ejbCreate, например), принимаются специальные меры, позволяющие обойти это ограничение.