Технология Enterprise JavaBeans (EJB)
Александр Цимбал
Enterprise JavaBeans является, возможно, именно той Java-технологией, которой язык Java обязан своей популярностью среди разработчиков корпоративных приложений. Она ориентирована на решение очень важной и непростой для эффективной реализации задачи - создание масштабируемых, устойчивых и надежных серверных приложений.
Введение
Интерес к программным средствам такого рода высок еще и потому, что прикладным разработчикам, в общем, не приходилось близко сталкиваться с этой проблемой. Господствующей архитектурой клиент-серверных приложений была (и остается) 2-хзвенная схема - сервер базы данных (или аналогичное ему стандартное программное обеспечение) и клиентские приложения. «Широкими массами» разработчиков накоплен богатый опыт работы «на стороне клиента», но проблемы обеспечения функционирования серверов касались, главным образом, системных администраторов. Прикладных программистов интересовал API клиента серверов СУБД, но не технологические подходы, обеспечивающие их эффективную работу.
С появлением многозвенной архитектуры неожиданно возникла проблема создания качественных серверов приложений. При этом затрагиваются такие вопросы, которые раньше считались прерогативой разработчиков программных средств, а не прикладных программ. Как обеспечить удаленное и универсальное взаимодействие клиентского и серверного приложения? Как создавать потоки для обработки клиентских запросов и управлять ими? Как и когда создавать объекты, непосредственно обслуживающие клиентские запросы? Каким образом обеспечить взаимодействие с конкретными серверами баз данных? Как обеспечить функционирование этих средств на различных платформах и под управлением различных операционных сред? Специалисты в каких областях нужны для разработки серверов приложений? Как обеспечить их совместную работу в рамках проекта?
Как всегда, наличие реальной проблемы стимулировала работы по ее решению. В настоящий момент дальше всего в этом направлении продвинулись три технологии - Enterprise JavaBeans и COM+ и CORBA.
Назначение и концепция
Самый элементарный анализ того, что такое «создание масштабируемых и эффективных серверов приложений с использованием Java», приводит к необходимости рассмотрения следующих проблем:
организация удаленных вызовов между объектами, работающими под управлением различных виртуальных машин Java;
управление потоками на стороне сервера;
управление циклом жизни серверных объектов (создание, взаимодействие с пользователем, уничтожение). Оптимизация использования ресурсов (время процессора, память, сетевые ресурсы). Такая задача требует создания некоторых сред по управлению объектами - «контейнеров».
создание схемы взаимодействия контейнеров и операционных сред;
создание схемы взаимодействия контейнеров и клиентов, включая универсальные средства создания разработки компонентов и включения их в состав контейнеров;
создание средств администрирования и обеспечение их взаимодействия с существующими системами;
создание универсальной системы поиска клиентом необходимых серверных компонентов;
обеспечение универсальной схемы управления транзакциями;
обеспечение требуемых прав доступа к серверным компонентам;
обеспечение универсального взаимодействия с СУБД.
Использование Java решает еще одну очень важную и непростую проблему - обеспечение всех вышеперечисленных требований на различных платформах и для различных операционных систем. Правда, возникает вопрос о производительности создаваемых программных комплексов (в настоящее время Java-программы в общем случае уступают в этом смысле своим C++-аналогам).
Спецификация EJB дает ответы на все вышеперечисленные вопросы. Как и всякая серьезная и универсальная технология, EJB имеет свою «философию». Вот ее основные положения:
необходима формализация процесса разработки распределенной системы с использованием EJB и взаимодействия различных его этапов между собой;
необходима формализация схемы взаимодействия клиентов и серверов;
необходима формализация взаимодействия серверов и операционной среды.
Здесь под «формализацией» понимается формулирование четких и обязательных к исполнению правил, которые призваны обеспечить решение всех проблем, требующих решения с точки зрения авторов концепции EJB. Повторим еще раз: EJB не претендует на роль универсальной системы разработки серверной части распределенных систем. Эта концепция оптимизирована для решения определенных классов задач, но зато в ее рамках достигается очень высокий уровень автоматизации процесса разработки и удобства сопровождения и администрирования.
Этапы создания ejb-проектов
Процесс разработки подразделяется на 5 этапов (6-ой этап, предусмотренный спецификацией EJB - этап администрирования). С каждым этапом сопоставлены вполне конкретные обязанности (роли):
Поставщик Сервера (Server Vendor))
Поставщик Контейнера (Container Vendor)
Разработчик Компонента (Bean Provider)
Сборщик Приложения (Application Assembler)
Установщик EJB (EJB Deployer)
Создание Серверов EJB и Контейнеров EJB (первые две роли) - проблема поставщиков инструментальных средств (BEA, INPRISE, Oracle, Sun и др.) При создании проектов прикладных разработчиков касаются вопросы, относящиеся к оставшимся трем ролям.
Bean Provider - это специалист в той прикладной области, в которой создается данный проект. Его задача - реализация необходимой заказчику функциональности системы. Такой разработчик, в общем, не должен быть специалистом ни в области сетевых технологий, ни в области управления транзакциями, ни в области взаимодействия с конкретными СУБД. Технология EJB и рассчитанные на взаимодействие с ней инструментальные средства (например, Borland JBuilder) позволяют автоматически генерировать «скелет» создаваемого компонента. Разработчику остается только дописать код необходимых методов.
Кроме этого, Разработчик Компонента может потребовать выполнения определенных условий на последующих этапах разработки. Например, он может обращаться к методам стандартного Java-интерфейса доступа к СУБД (JDBC), но при этом не указывать URL конкретного драйвера - на этом этапе создания компонента этот URL либо может быть еще просто неизвестен, либо компонент должен уметь работать с любым драйвером. В этом случае Разработчик резервирует место под URL конкретного драйвера в специальной структуре описания создаваемого компонента - так называемом Дескрипторе Развертывания (Deployment Descriptor), а в код компонента помещает команды извлечения конкретного URL из Дескриптора, которые выполняются в процессе работы программы. Указание реально используемого URL должно быть выполнено (без этого Компонент нельзя будет поместить в Контейнер) на любой из последующих стадий разработки - обычно на стадии Развертывания (Deployment).
Application Assembler, как и Bean Provider, является специалистом в прикладной области, и его задача - использовать готовые Компоненты либо для создания готового приложения, либо для создания новых, «укрупненных» Компонентов. На этой стадии обычно создается код для взаимодействия компонентов, например, с сервлетами, JSP или друг с другом. Любая информация, помещенная в Дескриптор Развертывания Разработчиком Компонентов, может быть дополнена или переопределена.
Delpoyer отвечает за присутствие всей необходимой информации в Дескрипторе Поставки и за ее корректность. Его не интересует код компонентов - его задача обеспечить их функционирование в данной операционной среде, определить права доступа к Компонентам и правила выполнения транзакций (кроме случая, когда компоненты сами управляют транзакциями), обеспечить взаимодействие с конкретными СУБД, разместить компоненты в нужные Контейнера. Вообще, под процессом развертывания приложения понимается совокупность всех действий по настройке системы в конкретной операционной среде, после которых клиент может приступить к работе с ней.
Важное место в технологии EJB занимают вопросы администрирования