Методология построения корпоративных информационных систем на основе технологии EJB. Часть 5

Дерево имен JNDI

JNDI (Java Naming Directory Interface). Расскажу немного подробнее об этом сервисе. Приведу хорошую аналогию. Мы постоянно пользуемся службой DNS не задумываясь как она работает и почему она появилась. Для тех кто плохо ориентируется в DNS я сейчас поясню основную идею. Как уже всем известно каждый компьютер подключенный к сети Internet имеет свой уникальный IP адрес. Например 213.10.2.4 или 194.145.90.158. Запоминать такие адреса человеку чаще всего сложно. И придумали сопоставлять каждому IP адресу определенное составное имя. Например kooper.favour.com или beta.alpha.rest.com. Такие имена значительно проще запомнить человеку. К тому же читая имя справа налево человек может видеть иерархию имен, т.е. есть сервер com к нему подключен сервер favour, а к favour подключен kooper. Конечно такая иерархи чаще всего условная и не имеет никакого отношения к реальному положению дел, но этот механизм позволяет примерно понять какой фирме принадлежит компьютер с таким именем. Побочным эффектом такого подхода стала очень интересная и удобная вещь. Так как теперь все используют имена в место конкретных IP адресов, в случае смены IP адреса не нужно оповещать всех об этом. Нужно только поменять соответствие между именем и IP адресом. Вы это бы хорошо оценили если бы у Вас был бы популярный Web-портал и в один прекрасный момент порталу перестало бы хватать пропускной способности канала провайдера и вам срочно нужно сменить старого интернет провайдера на нового и не хотелось бы терять посетителей которые помнят Ваш IP адрес, т.к. новый провайдер выдаст вам новый IP адрес. А тут все просто. Смени у имени в DNS старый IP адрес на новый. И пользователи Вашего портала ничего не заметят.

А теперь вернемся к службе JNDI. Каждому компоненту EJB сопоставляется имя, которое публикуется на дереве имен JNDI. И клиентское приложение обращается к этой службе зная имя под которым зарегистрирован EJB компонент. Обратившись к службе имен клиентское приложение получает по имени объектную ссылку. На самом деле существует менее изящный способ получения объектной ссылки. Но для начала я думаю необходимо пояснить, что такое объектная ссылка. Так как изначально полагается что компоненты работают в разных адресных пространствах с клиентским приложением, т.е. в разных виртуальных машинах и все их взаимодействие является сетевым, то не совсем понятно что такое объектная ссылка в этом случае. Классически объектная ссылка это можно сказать адрес в памяти, но в случае удаленного взаимодействия это адрес хоста, номер порта, плюс много всякой служебной информации и плюс еще к тому что эта объектная ссылка уникальная и ее значение не возможно предсказать. Самым первый способ получения объектной ссылки выглядит так: запускается компонент на стороне сервера и полученная объектная ссылка записывается в файл и передается на сторону клиента. Можно ее перенести на дискете или передать по FTP или получить с web сервера по http. Не очень красивое решение. Сервис именования JNDI позволяет по имени получить объектную ссылку компонента. Сценарий запуска сервера и взаимодействия клиента уже выглядит следующим образом: запускается компонент на стороне сервера, который себя регистрирует на дереве имен JNDI под заранее оговоренным с клиентом именем, а потом клиентское приложение через сервис JNDI по имени получает объектную ссылку на этот компонент.

Еще одним преимуществом использования сервиса JNDI проявляется в следующей ситуации. Предположим Вы разработали 6 компонентов EJB, эти компоненты общаются с друг другом для выполнения запросов поступающих со стороны клиентского приложения. И вот настал тот долгожданный день, когда Ваш сервер приложений перестал справляться с вычислительной нагрузкой. И вот Вы решили компоненты EJB разместить на 3 серверах предложений. Переход от одного сервера приложений к трем изображен на рис. 11.

Рис.11

Как видно из рисунка, все компоненты EJB зарегистрированы на сервисе JNDI и при взаимодействии сначала ищут друг друга на JNDI. В случае когда их разместили на разных серверах приложений, компоненты даже ничего не заметили так как доступ к соседним компонентам получали через сервис JNDI. И естественно клиентское приложение, тоже ничего не почувствовало. Что же мы получаем в итоге? Мы распределили наши компоненты на разные вычислительные машины и при этом не изменили ни одной строчки кода ни в клиентском приложении ни в самих компонентах.

TOC | Часть 6