Введение
Думаю, расхваливать то, что будет написано мной сразу не стоит. Лучше сказать чего я постараюсь не написать. Если Вы хотите увидеть здесь учебник по которому можно научится основам EJB, то лучше Вам почитать книжки типа Corba за 14 дней. Если Вы ждете моих вздохов по перспективности и крутости технологии EJB, то Вам лучше почитать обзоры популярных компьютерных журналов. Если Вы ожидаете найти здесь обилие исходных примеров, да еще что бы они компилировались и работали, то Вам лучше почитать Manual от любого поставщика коммерческой или некоммерческой версии EJB сервера. В общем получается, что не совсем понятно, для кого я это все буду писать. Не знаю, как даже охарактеризовать моего потенциального читателя. Думаю, что я пишу это для себя самого. Но не для себя в данный момент, а для себя несколько месяцев назад. Дело в том, что не так давно я писал линейные программы без объектно-ориентированного подхода. Хотя прекрасно знал об ООП, но не использовал, так как считал это неудобным. Мне, к сожалению, пришлось решать несколько довольно сложных задач. И решал я их без ООП. Решал вполне успешно. Но вот когда пришло время модернизации разработанных систем... Я был просто подавлен. И тут меня судьба свела с человеком, который мне показал способы применения ООП: отображение объектов в БД, коллекции объектов и т.д. Имя этого человека Сергей Резинкин. Выражаю ему благодарность. Если бы не он... Другими словами мне нужен был толчок в верном направлении. Я стал интересоваться UML, потом CORBA, потом вышел на EJB и многое другое. Так вот я хочу Вам дать толчок в верном направлении. Я обозначу Вам путь. Многое здесь Вы, возможно, не воспримите по причине краткости изложения или отсутствия опыта, который бы позволил верно воспринять некоторые вещи. Надеюсь Вас задеть, что бы Вы сами дальше начали копать в этом направлении.
Чаще всего системы строятся следующим образом. Есть клиентское приложение, которое соединяется с сервером БД и посредством SQL запросов манипулирует данными, отображаемыми в клиентском GUI интерфейсе. Клиентская часть таких систем обычно очень сложная и на сервер баз данных возлагается, в основном задача, хранения и поддержки целостности данных. Иногда базы данных поддерживают хранимые процедуры, что позволяет снизить сетевой трафик между сервером и клиентом. Такая система изображена на рис. 1.
Рис.1
Такой подход имеет свои плюсы и минусы. В плюс идет относительно простая архитектура системы и относительно высокая скорость работы при небольшом количестве клиентских обращений к серверу. В минус идет то, что такую систему сложно модернизировать, так как изменение в БД влекут за собой изменения в клиентской части и наоборот. В случае нехватки ресурсов сервера, приходится либо наращивать его вычислительную мощность либо использовать распределенную БД, которая не всегда сможет решить возникшую проблему.
Существует другой подход построения информационных систем. Система разделяется на три уровня. Каждый уровень имеет свои обязанности и функциональные возможности. На первом уровне находится клиентское приложение, которое обычно "легкое" и занимается в основном презентационным слоем системы. Второй уровень отвечает за бизнес логику системы и взаимодействует с презентационным слоем, отвечая на его запросы. Вторым уровнем называют сервер приложения. На третьем уровне находится база данных, которая, как уже говорилось выше, отвечает за хранения данных и за их целостность. Такая система изображена на рис. 2.
Рис.2
Такой подход тоже имеет свои плюсы и минусы. В плюс идет разделение системы на уровни, позволяющее относительно легко модернизировать систему. Например, сегодня у Вас СУБД MySQL, а завтра Вы купили ORACLE и для этого Вам нужно поправить только второй уровень, а презентационный слой даже не заметит изменений. Или, например, Ваш второй уровень не очень оптимально работает и Вы решили его усовершенствовать, нет проблем: первый и третий уровень могут быть не затронуты. Еще одним преимуществом является возможность групповой работы над системой, в которой каждый из уровней разрабатывается независимо. Кто-то проектирует структуры баз данных, кто-то "рисует" презентационные слои, а кто-то пишет оптимальные алгоритмы. В добавок ко всему, компонентная технология EJB ориентирована на возможность распределения второго уровня, т.е. если Ваш сервер приложений не справляется с нагрузкой, то есть возможность без единого изменения кода сервера приложений, разнести его на несколько вычислительных машин. А компоненты, из которых состоит второй уровень, не будут чувствовать разницы между работой на одной вычислительной машине и на нескольких машинах. Минусом таких систем является их направленность на крупные корпоративные решения. Если Вы решаете задачу в которой небольшое количество обращений к серверу и малый бюджет на создание системы, то связавшись с EJB Вы будете стрелять из пушки по воробьям.
Многие спросят, а зачем вообще пользоваться EJB технологией? Можно и самому построить такую же систему, например, используя C++. Это конечно верно, но Вы будете изобретать велосипед и придете к такому же архитектурному решению, как в EJB, да и к тому же создание такой архитектуры довольно не тривиальная задача. Значительно дешевле и быстрей разобраться в правилах построения компонентов EJB архитектуры и строить по ее принципам свою систему на отлаженных технологиях. Да, чуть не забыл: EJB - Enterprise JavaBeans. Кстати на счет CORBA. Кто-то спросит, а почему бы не использовать CORBA архитектуру вместо EJB, которые работают не на очень скоростном языке JAVA? Отвечу довольно просто. В CORBA пока что не готова спецификация компонентов CORBA. Ну а тем более нет реализаций еще не готовой спецификации. Ну а кто вспомнит про DCOM, тех отсылаю к статьям, где проводится сравнительный анализ с CORBA, а после прочтения этих статей мой ответ сводится к тому, что DCOM пытается конкурировать с CORBA и проигрывает по нескольким критериям, да и к тому же не является компонентной технологией в "чистом" виде как EJB.
На самом деле JAVA продвигает 5 уровневую архитектуру на основе EJB, показанную на рис.3.
Рис.3
Пояснять ее я не буду, дабы не запутать читателя, а привел только для того, что бы часть читателей успокоилось на счет возможности построения много-уровневых систем на основе EJB.
СЕРВЕР ПРИЛОЖЕНИЙ
Самое главное в EJB это сервер приложений. Без него у Вас ничего работать не будет. Клиентские приложения будут общаться с ним через RMI или CORBA. Обычно сервер приложений предоставляет Вашим EJB компонентам соответствующую среду. Например: хранит права доступа к Вашим компонентам (а точнее логины с паролями по доступу к серверу приложений), поддерживает RMI и CORBA взаимодействие с ними, предоставляет JNDI сервис (сервис именования EJB компонентов), координатор транзакций и контейнер, в котором будут храниться ваши EJB компоненты, сервис асинхронных сообщений JMS. Специалисты, которые это прочтут, будут возмущены грубыми ошибками. Дело в том, чтобы не грузить читателя, я довольно упростил и смешал некоторые вещи. Сервер Приложений изображен на рис. 4.
Рис. 4
Как видно из рисунка, есть компьютер, на котором работает сервер и к нему есть доступ через RMI и CORBA. Внутри самого сервера приложений работают четыре службы и контейнер. Теперь немного подробнее о службах.
JNDI (Java Naming Directory Interface) - эта служба позволяет Вашим клиентскими приложениям находить на сервере приложений EJB компоненты по их имени. На самом деле Вы можете взять 10 компьютеров, объединить их в сеть, установить на них сервера приложений. Но сервис JNDI включить только на одном из них. И получится, что все компоненты EJB будут доступны на одном дереве имен, а работать на разных серверах приложений. Конечно, не зря я применяю термин дерево имен. Дело в том, что эта служба очень похожа на древовидную файловую структуру, где есть папки (контексты) и файлы (EJB компоненты). Я рассказываю это к тому, что на самом деле можно запустить на всех 10 компьютерах JNDI сервис, но настроить их так, что какой-то один из этих сервисов будет корневым, а все остальные будут подключены к нему и на общем дереве имен будут показаны как папочки (контексты).
Transaction Service - сервис транзакций. Этот сервис предоставляет похожие услуги транзакций, как в обычных реляционных базах данных. Только в данном случае нет SQL запросов и нет строчек базы данных вовлеченных в транзакцию. Вместо SQL запросов Вы вызываете методы изменяющие состояния компонентов и как только Вы начали транзакцию, то все объекты, с которыми Вы начнете работать, будут в нее вовлечены. В конце Вы можете откатить изменения, сделанные Вами в объектах либо зафиксировать их.
Security Service - сервис безопасности. Так как сервер приложений предоставляет удаленный доступ к EJB компонентам, то вообще-то очень хорошо бы этот доступ ограничить. Для этого этот сервис и нужен.
JMS (Java Message Service) - сервис асинхронных сообщений. Есть возможность послать сообщение и не ждать подтверждение о получении или ответа. Например, когда Вы вызываете метод удаленного компонента, то Вам придется ждать, пока компонент отработает и вернет Вам значение. Хотя Вы конечно можете что-то делать в других нитях Вашего приложения. На самом деле JMS берет всю ответственность за доставку и хранения очередей сообщений, что значительно разгружает клиентские приложения. Поддерживаются механизмы: точка к точке, подписка, рассылка. Также, на стороне JMS подписчик может установить фильтр и получать только те сообщения, которые его интересуют.
Контейнер это контейнер. Он предоставляет среду, в которой могут функционировать Ваши компоненты EJB. Получается, у Вас есть контейнер, в который вы можете запихивать свои компоненты.
Каковы функции контейнера? Их много:
- Разбор XML-описания компонента EJB (deployment descriptor) и поддержка конфигурации, описанной в этом XML-файле.
- Управление жизненным циклом компонента EJB, т.е. для предоставления услуг компонента прописанных в его интерфейсе и зарегистрированном на JNDI, необходимо создавать, уничтожать и кэшировать реализации (объекты), которые будут отвечать на запросы клиентов.
- Разбалансировка нагрузки между реализациями (объектами) обслуживающими компонент EJB и управление пулом таких объектов.
- Управление транзакциями в компонентах EJB. В случае с компонентами, которые работают с СУБД, управление транзакциями сильно связано с механизмом синхронизации состояния компонентов с состоянием СУБД.
- Управление безопасностью доступа к компонентам. Опционально эта функция может быть отключена и проверку прав доступа к методам Вашего компонента придется реализовывать своими руками в самом компоненте.
Контейнер изображен на рис. 5.
Рис. 5
Для того, что бы понять, что же на самом деле такое эти компоненты EJB, необходимо усвоить некоторые идеи компонентной модели. Следует уяснить, если Вы используете компонентную модель, значит, строительными блоками модели являются компоненты, имеющий стандартный внешний вид, с помощью которого можно эти компоненты состыковывать. Другими словами, если вы будете использовать такую модель Вам необходимо строго придерживаться стандартов описывающих внешний вид ваших компонентов. Внутренности Ваших компонентов, это Ваша проблема, Вы вольны реализовывать функционал, как Вам угодно, правда есть некоторые рекомендации, которые Вам принесут больше пользы, чем вреда.
Компоненты EJB имеют, вольно выражаясь, два внешних описания (интерфейса). Через них, собственно, клиент и взаимодействует с Вашим компонентом.
Пример этого изображен на рис. 6
Рис. 6
Home-интерфейс, является точкой входа в Ваш компонент или фабрикой компонента. Другими словами любое начало взаимодействия с Вашими компонентами происходит через Home-интерфейсы. Клиент обращается к интерфейсу и создает через него экземпляры (объекты), которые обслуживают данный компонент. А в конце своей работы он их уничтожает.
Remote-интерфейс позволяет взаимодействовать с экземплярами (объектами), которые были созданы через фабрику (Home-интерфейс). Через Remote-интерфейс пользователь вызывает бизнес-методы компонента, которые естественно Вам придется реализовывать, запихивая туда логику Вашего приложения.
Разберем стандартный сценарий взаимодействия клиента с компонентами EJB. Взаимодействие изображено на рис. 7
Рис. 7
1: Клиент ищет Home-интерфейс нужного ему компонента по его имени через сервис имен JNDI (клиенту возвращается в результате поиска Home-интерфейс этого найденного компонента).
2: Клиент, через найденный Home-интерфейс, вызывает функцию создания экземпляра компонента на стороне сервера (клиенту возвращается Remote-интерфейс созданного экземпляра компонента).
2.1: Сервер создает этот экземпляр.
3: Клиент вызывает бизнес-метод на созданном компоненте через его Remote-интерфейс этого компонента.
3.1: Сервер вызывает бизнес-метод на конкретном экземпляре компонента.
На стороне клиента Remote-интерфейс и Home-интерфейс оформлены в виде классов, которые скрывают сетевые взаимодействия на основе RMI с сервером приложений. Клиент работает с объектами, думая, что они работают в том же адресном пространстве, что и само приложение, а на самом деле происходят сетевые вызовы и функционал объектов работает совсем на другой вычислительной машине.
Как уже говорилось выше, вся работа с компонентами начинается с обращения к Home-интерфейсу. Каждый тип компонент должен его иметь. Пример Home-интерфейса изображен на рис. 8.
Рис. 8
В этом интерфейсе Вы должны определить методы двух типов. Это фабричные методы create и поисковые find.
Фабричные методы позволяют Вам создавать для себя экземпляры компонентов на стороне сервера. При вызове этого метода Вы можете передать параметры инициализации компонента. Можно иметь несколько фабричных методов с разным числом параметров. При вызове фабричного метода Вам возвращается ссылка созданного компонента на стороне сервера. Получив эту ссылку, Вы можете начать общение с созданным компонентом, т.е. Вызывать его бизнес методы.
Поисковые методы позволяют найти уже созданные компоненты на стороне сервера. Поисковые методы применимы только к компонентам, которые называются EntityBean или, по-русски, сущностные бины. Другими словами, время жизни таких компонентов превышает время работы сервера приложений и, чаще всего, состояние таких компонентов отображается в реляционные базы данных. Поисковые методы по результату действия очень похожи на фабричные, но они могу возвращать не только ссылку на один компонент, но и коллекцию ссылок нескольких найденных компонентов. Еще одно отличие. При вызове поискового метода Вы передаете условие поиска компонентов, и по этому условию происходит выборка компонента из базы данных.
После того, как Вы создали или нашли компонент через его Home-интерфейс и получили ссылку на его Remote-интерфейс, можно приступить к взаимодействию с этим EJB-компонентом. Все способы взаимодействия с компонентом строго определены в полученном Remote-интерфейсе. Пример Remote-интерфейса изображен на рис. 9.
Рис. 9
Стандартом, конечно, являются get/set-методы, считывающие и устанавливающие состояния параметров EJB-компонентов. Можно определить любые методы в Remote-интерфейсе, например пересчета суммы из одной валюты в другую по такому-то курсу второй валюты относительно первой.
После того как Вы определили Home и Remote интерфейсы своего компонента, необходимо написать реализации методов определенных в них. К некоторым методам в реализации добавляется приставка ejb. Пример реализации выше рассмотренного компонента показан на рис. 10.
Рис. 10