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




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


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

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

JavaBeans и Enterprise JavaBeans

26.08.2003

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

Введение

Компонентная модель определяет среду, которая поддерживает многоразовые компоненты для приложений. В Java в качестве базовой компонентной модели принята технология JavaBeans, созданная для соединения воедино конструктивных элементов (некоторые говорят: как в конструкторе Lego), и построения из них апплетов и приложений. На сегодня разработано достаточно много компонентов JavaBeans и большое количество инструментальных средств, поддерживающих их работу.

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

Структура JavaBean

Любой объект, подчиняющийся определённым требованиям (перечисленным в JavaBeans API), может считаться компонентом JavaBean ("бин"). Кроме того, такой JavaBean помимо наличия в нем конструктора и способности к сериализации может экспортировать свойства (properties), события (events) и методы (methods). Свойства отражают внутреннее состояние бина, и ими можно манипулировать с помощью методов get и set (getter/setter methods). Бин также способен генерировать события в соответствии с правилами Java 1.1 Delegation Event Model. Бин определяет события с помощью соответствующих методов для добавления и удаления слушателей (listener objects), расположенных в списке заинтересованных в этом событии слушателей. Методы бина могут быть как открытыми (public methods), которые видны пользователю и с помощью которых можно изменять значения свойств, так и методами для регистрации и удаления слушателей событий.

Кроме этого, бины также имеют индексируемые свойства (indexed properties), связанные свойства (bound properties) и свойства с фиксированным набором значений (constrained properties). Индексируемое свойство - это свойство, у которого есть значение массива и набор методов для измения значения любого из элементов этого массива или целиком всего массива. Связаное свойство - это свойство, которое с помощью событий сообщает об изменениях своего значения. Свойство с фиксированным набором значений - это свойство, которое не только сообщает об изменении своего значения, но и предоставляет право своим слушателям запретить это изменение.

Бин также может содержать класс BeanInfo, который предоставляет дополнительную информацию о самом бине в виде объектов Feature Descriptor (описание свойств) для каждой из имеющихся характеристик бина. Если бин имеет достаточно сложный тип свойств, ему, возможно, понадобится класс PropertyEditor, позволяющий пользователю устанавливать свои значения для этого свойства. Бин также может иметь класс Customizer, предназначенный для создания пользовательского GUI для настройки бина.

Надстройка над Java

JavaBean является надстройкой над традиционной Java-технологией, хотя ни в чём ей не противоречит и использует только Java-конструкции, синтаксис и семантику Java-классов и интерфейсов. Однако JavaBean - это не просто библиотеки классов: компоненты могут иметь изменяемые свойства, наборы методов и порождать события. Событийная модель в компонентах очень изощрённая. Например, изменение свойств какого-либо компонента может служить источником события и об этом извещаются другие компоненты, в том случае, если они зарегистрированы на обработку этого события в качестве подписчиков. Само извещение иногда называют распространением события, и при этом у объектов подписчиков вызывается специальный метод обработки события. Самое интересное заключается в том, что всегда можно выяснить, что может и чего не может тот или иной компонент. Компонент обязан афишировать свои характеристики, в которые входят:

- методы, которые нужно вызвать;

- свойства, которые можно изменять;

- события, которые можно обрабатывать.

Выяснение данных характеристик со стороны других компонентов называется интроспекцией. В архитектуре Java эти методы были реализованы изначально и заключены в базовый класс java.lang.reflect. Тем не менее, в архитектуре JavaBean существуют дополнительные классы BeanInfo и Introspector.

Хотя в базовой концепции JavaBean описываются только локальные взаимодействия компонентов в пределах одной виртуальной Java-машины, на самом деле подразумевается, что эти компоненты могут находиться где угодно, и что они могут взаимодействовать друг с другом по протоколу RMI или CORBA.

После того как компонент разработан, он может быть сохранен на компьютере в точности так же, как и обычный файл. Java помнит структуру объекта, и вы, при желании, всегда можете воспользоваться интерфейсом java.io.Serializable, чтобы получить стандартную форму графа объектов, или преобразовать компонент при помощи интерфейса Exsternalizable, когда надо представить компонент в качестве элемента другой объектной среды, например, ActiveX. Естественно, что слишком большие компоненты нужно упаковать, и это даже рекомендуется для снижения трафика сети, когда вы работаете в распределенной системе. Для этого используется стандартный Java-архиватор, который создает файлы с расширением jar. Java-архивы могут содержать классы, изображения, справочную информацию, и к каждому архиву может быть прикреплен специальный файл manifest, описывающий содержание архива и связи между компонентами.

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

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

При проектировании компонента Bean, обычно принимается следующее:

1. Для свойства с именем ххх обычно создаются два метода: getXxx() и setXxx(). По этим методам можно установить и получить свойства объекта.

2. Для логического типа используется нечто подобное, но с именем "is" вместо "get".

3. Для событий используется ключевое слово "listener", например, addFooBarListener (FooBarListener) или removeFooBarListener (FooBarListener), чтобы обрабатывать событие FooBarEvent. Большинство событий и встроенных обработчиков, как правило, устраивают разработчиков, но не возбраняется написать свой собственный listener для обработки какого-нибудь специфического события.

Преимуществом открытой архитектуры JavaBean является возможность миграции из приложений, основанных на применении ActiveX-решений, в кроссплатформенный мир чистого Java благодаря технологии, известной как JavaBeans Architecture Bridge for ActiveX. Кроме того, при взаимодействии двух Beans, находящихся в одном ActiveX-контейнере, после первоначальной установки соединения компоненты могут связываться друг с другом без использования COM. Это позволяет JavaBean-компоненту получать и обрабатывать события других JavaBean-компонентов, выполняющихся в том же самом контейнере без дополнительных усилий взаимодействия со всеми уровнями COM.

Термин "Enterprise JavaBeans"

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

Упакованный компонент EJB можно определить по наличию следующих элементов:

1. a. home-интерфейс

b. home-объект

2. a. remote-интерфейс

b. объект EJB - реализация remote-интерфейса, который в целях простоты называется EJBObject.

3. Непосредственно реализация бина - это код реализации бизнес-логики. Здесь это будет называться Enterprise Bean.

4. Описание его установки и применения.

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

Архитектура EJB

EJB задумана как архитектура и как средство для построения сложных компонентно-распределённых систем. В качестве архитектурного решения была создана программная спецификация, которая является основанием для разработки программных продуктов третьими фирмами, не исключая и саму фирму Sun - создателя и первичного публикатора этой спецификации; в качестве средства была создана специальная редакция Java и Java Development Kit (JDK), получившая название Java 2 Platform, Enterprise Edition (J2EE). J2EE включает в себя средства EJB и все необходимые API для обращения к этим средствам.

При создании Enterprise JavaBeans были поставлены следующие амбициозные цели:

- архитектура Enterprise JavaBeans является стандартной компонентной архитектурой для построения распределённых объектно-ориентированных бизнес-приложений на языке программирования Java;

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

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

- архитектура Enterprise JavaBeans должна отражать все аспекты жизненного цикла программного обеспечения;

- архитектура Enterprise JavaBeans полностью совместима с CORBA-протоколами.

Большое значение в архитектуре EJB имеет понятие EJB-сервера. EJB-сервер предоставляет среду выполнения приложений, основанных на применении JavaBeans. Главной его задачей является планирование ресурсов и координация работы приложений, использующих технологию Enterprise JavaBeans. EJB-сервер должен содержать один или более контейнеров с объектами в виде Beans, которые могут распределённо вызываться и использоваться, никуда при этом не перемещаясь и оставаясь на сервере.

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

EJB-контейнер действует как транспортный механизм между клиентом и Enterprise Bean. В момент развёртывания приложения контейнер генерирует EJB.

Home-интерфейс служит для представления классов, а EJB Object-интерфейс - для каждого экземпляра Bean. EJB Home-интерфейс (в виде Bean-идентификатора) доступен через стандартное средство Java (JNDI - Java naming and directory) и идентифицирует Bean-класс, который используется для создания, нахождения и удаления экземпляров объекта данного класса. Интерфейс EJB Object (как представление клиента) обеспечивает доступ к бизнес-алгоритмам, которые реализует выбранный Bean. Все клиенты должны запрашивать эти интерфейсы. Клиентские запросы перехватываются EJB-контейнером, который координирует транзакции и прочие операции взаимодействия объектов. Таким образом, EJB - это целостная концепция распределённого объектного управления, включающая в себя все необходимые механизмы, в том числе и транспортные, и сетевые, и транзакционные.

Клиентская часть EJB обеспечивается двумя интерфейсами:

- Home Interface, который обеспечивает методы для создания, удаления и обнаружения объектов в контейнере. Клиент может использовать JNDI для поиска имён соответствующих классов;

- Remote Interface, который определяет бизнес-методы, предлагаемые выбранным Bean.

EJB-классы и экземпляры классов осуществляют при этом три категории содержащихся в них и дистанционно вызываемых методов:

- методы для создания, нахождения и доступа к экземплярам объектов посредством home-интерфейса;

- методы, поддерживающие бизнес-алгоритмы посредством remote-интерфейса;

- методы интерактивного взаимодействия внутри контейнера (скрытые для клиентов)

Отличие EJB от JB

Так чем же EJB отличается от обычного JavaBean? С точки зрения сущности - ничем, а с точки зрения построения и способов использования - многим. В узком смысле можно сказать, что архитектура EJB логически расширяет возможности компонентной модели JavaBean так, чтобы иметь возможность поддерживать компоненты для серверов.

Если брать более широко, то можно утверждать, что EJB - это концепция многомашинных распределённых архитектур, включающая в себя все требуемые звенья. Это самодостаточная система, которая содержит в себе всё необходимое. Что надо, чтобы перейти от простого JavaBean к EJB? Компонентная модель EJB-сервера определяет набор стандартных, независимых от производителя, интерфейсов для всех серверов приложений. Приложения класса enterprise (промышленные приложения) требуют доступа к различным инфраструктурным сервисам: распределённым процессам, коммуникациям, работы с деревом каталогов, управления транзакциями, обмена сообщениями, доступа к данным, а также возможности совместного использования ресурсов. Данные инфраструктурные сервисы часто реализуются на различных платформах посредством различных продуктов и технологий, что вызывает трудности при создании переносимых систем приложений класса enterprise. Возможности переносимости EJB-компонентов становятся реальными благодаря платформе Enterprise Java (Java2EE).

Основы технологии EJB

Для того чтобы понять, как работает и как устроена EJB-система, сначала необходимо рассмотреть ее основные части: EJB-компонент (component), EJB-контейнер (container) и EJB-объект (object).

EJB-компонент (The Enterprise JavaBeans component)

Компоненты EJB выполняются внутри EJB-контейнера, который, в свою очередь, выполняется внутри EJB-сервера. Любой сервер, который в состоянии поддерживать EJB-контейнеры и предоставлять им необходимые сервисы, может быть EJB-сервером (то есть многие из существующих серверов могут быть просто расширены до поддержки Enterprise JavaBeans).

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

EJB-контейнер (The Enterprise JavaBeans container)

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

EJB-объект (EJB-object) и удаленный интерфейс (remote interface)

Клиентские приложения вызывают методы на удаленных EJB-компонентах через EJB-объект (EJB-object). EJB-объект реализует "удаленный интерфейс" EJB-компонента на сервере. Суть в том, что находящийся на сервере EJB-компонент, помимо бизнес-функций, ради которых он был разработан, должен реализовывать также некоторые функции, определяемые спецификацией, которые служат для "управления" EJB-компонентом со стороны контейнера. EJB-объект реализует лишь бизнес-интерфейс для EJB-компонента, являясь, в некотором смысле, "промежуточным" звеном между клиентом и EJB-компонентом.

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

Этапы создания EJB-проектов

Процесс разработки подразделяется на 5 этапов. Дополнительно существует этап администрирования. С каждым этапом сопоставлены вполне конкретные обязанности и роли:

1. Поставщик Сервера (Server Vendor)

2. Поставщик Контейнера (Container Vendor)

3. Разработчик Компонента (Bean Provider)

4. Сборщик Приложения (Application Assembler)

5. Установщик EJB (EJB Deployer)

Создание серверов EJB и контейнеров EJB (первые две роли) - проблема поставщиков инструментальных средств (BEA, INPRISE, Oracle, Sun и др.) При создании проектов, прикладных разработчиков касаются вопросы, относящиеся к оставшимся трем ролям.

Bean Provider - это специалист в той прикладной области, в которой создается данный проект. Его задача - реализация необходимой заказчику функциональности системы. Такой разработчик, в общем, не должен быть специалистом ни в области сетевых технологий, ни в области управления транзакциями, ни в области взаимодействия с конкретными СУБД. Технология EJB и рассчитанные на взаимодействие с ней инструментальные средства позволяют автоматически генерировать "скелет" создаваемого компонента. Разработчику остается только дописать код необходимых методов.

Кроме этого, Разработчик Компонента может потребовать выполнения определенных условий на последующих этапах разработки. Например, он может обращаться к методам стандартного Java-интерфейса доступа к СУБД (JDBC), но при этом не указывать URL конкретного драйвера - на этом этапе создания компонента этот URL либо может быть еще просто неизвестен, либо компонент должен уметь работать с любым драйвером. В этом случае разработчик резервирует место под URL конкретного драйвера в специальной структуре описания создаваемого компонента - так называемом Дескрипторе Развертывания (Deployment Descriptor), а в код компонента помещает команды извлечения конкретного URL из Дескриптора, которые выполняются в процессе работы программы. Указание реально используемого URL должно быть выполнено (без этого компонент нельзя будет поместить в Контейнер) на любой из последующих стадий разработки - обычно на стадии Развертывания (Deployment).

Application Assembler, как и Bean Provider, является специалистом в прикладной области, и его задача - использовать готовые компоненты либо для создания готового приложения, либо для создания новых, "укрупненных" компонентов. На этой стадии обычно создается код для взаимодействия компонентов, например, с сервлетами, JSP или друг с другом. Любая информация, помещенная в Дескриптор Развертывания Разработчиком Компонентов, может быть дополнена или переопределена.

Delpoyer отвечает за присутствие всей необходимой информации в Дескрипторе Поставки и за ее корректность. Его не интересует код компонентов - его задача обеспечить их функционирование в данной операционной среде, определить права доступа к компонентам и правила выполнения транзакций (кроме случая, когда компоненты сами управляют транзакциями), обеспечить взаимодействие с конкретными СУБД, разместить компоненты в нужные Контейнеры. Вообще, под процессом развертывания приложения понимается совокупность всех действий по настройке системы в конкретной операционной среде, после которых клиент может приступить к работе с ней.

WORA

Архитектура Enterprise JavaBeans определяет стандартную модель для серверов Java-приложений, которая должна удовлетворять условию переносимости. "Написанное однажды выполняется везде" (WORA). WORA является одним из основополагающих принципов, лежащих в основе Java-технологии. Виртуальная Java-машина(JVM) позволяет любому Java-приложению выполняться в любой операционной системе. Однако для серверных компонентов требуются дополнительные возможности, которые не обеспечиваются напрямую самой JVM. Эти услуги может предоставить либо сервер приложения, либо какая-то распределённая объектная инфраструктура, типа CORBA или DCOM. Ранее всё происходило следующим образом: каждый сервер приложений поставлял набор программных интерфейсов, дающих доступ к такого рода услугам, а компоненты для серверов не имели способности переноситься с одного сервера приложений на другой. Компонентная модель EJB-сервера определяет набор стандартных, независимых от производителя, интерфейсов для всех серверов Java-приложений.

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

EJB, RMI и CORBA

Вообще существуют и конкурируют несколько технологий создания серверных приложений. К таковым помимо EJB относятся RMI и 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, как видите, не страдают отсутствием амбиций, но даже если эти планы и будут полностью реализованы, то это произойдет не завтра. Программисты же, которые нуждаются в средствах создания качественных корпоративных приложений, хотят иметь их уже сейчас.

Компонентная модель 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.

Интерфейс Java, соответствующий спецификации RMI/IDL, должен соответствовать следующим требованиям:

- этот интерфейс явно или неявно должен наследовать интерфейс java.rmi.Remote;

- все его базовые интерфейсы соответствуют требованиям RMI/IDL;

- все методы интерфейса должны возбуждать исключение java.rmi.RemoteException;

- все аргументы методов и возвращаемые типы должны соответствовать требованиям RMI/IDL, предъявляемым к типам. Тип считается соответствующим требованиям RMI/IDL, если он либо один из базовых типов языка Java, либо это ссылка на удаленный объект, либо это любой класс Java, реализующий (явно или неявно) интерфейс java.io.Serializable, либо это массив всех ранее перечисленных типов, либо это исключение, либо это тип java.lang.Object.



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