<< Часть 1

Методология построения корпоративных информационных систем на основе технологии EJB (Часть 2, 3)

© Евгений Игумнов
Опубликовано на сайте http://ejbcorba.euro.ru

• Сервер приложений
• Контейнер
• Компонентная модель

СЕРВЕР ПРИЛОЖЕНИЙ

Самое главное в 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. Получается, у Вас есть контейнер, в который вы можете запихивать свои компоненты.

Каковы функции контейнера? Их много:

1. Разбор XML-описания компонента EJB (deployment descriptor) и поддержка конфигурации, описанной в этом XML-файле.
2. Управление жизненным циклом компонента EJB, т.е. для предоставления услуг компонента прописанных в его интерфейсе и зарегистрированном на JNDI, необходимо создавать, уничтожать и кэшировать реализации (объекты), которые будут отвечать на запросы клиентов.
3. Разбалансировка нагрузки между реализациями (объектами) обслуживающими компонент EJB и управление пулом таких объектов.
4. Управление транзакциями в компонентах EJB. В случае с компонентами, которые работают с СУБД, управление транзакциями сильно связано с механизмом синхронизации состояния компонентов с состоянием СУБД.
5. Управление безопасностью доступа к компонентам. Опционально эта функция может быть отключена и проверку прав доступа к методам Вашего компонента придется реализовывать своими руками в самом компоненте.

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

Продолжение>>

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме Borland
Отправить ссылку на страницу по e-mail