Корпоративные информационные системы

ную мощность либо использовать распределенную БД, которая не всегда сможет решить возникшую проблему.

Существует другой подход построения информационных систем. Система разделяется на три уровня. Каждый уровень имеет свои обязанности и функциональные возможности. На первом уровне находится клиентское приложение, которое обычно «легкое» и занимается в основном презентационным слоем системы. Второй уровень отвечает за бизнес-логику системы и взаимодействует с презентационным слоем, отвечая на его запросы. Вторым уровнем называют сервер-приложения. На третьем уровне находится база данных, которая, как уже говорилось выше, отвечает за хранение данных и за их целостность. Такая система изображена на рис. 8.2.

Рис. 8.2.

Такой подход тоже имеет свои плюсы и минусы. В плюс идет разделение системы на уровни, позволяющее относительно легко модернизировать систему. Например, если появилась необходимость заменить СУБД MySQL на ORACLE, то для этого нужно по-

351

править только второй уровень, а презентационный слой даже не заметит изменений. Или, например, второй уровень не очень оптимально работает и при решении его усовершенствовать, то проблем невозникает: первыйитретийуровеньмогутбытьнезатронуты.

Еще одним преимуществом является возможность групповой работы над системой, в которой каждый из уровней разрабатывается независимо. Кто-то проектирует структуры баз данных, кто-то «рисует» презентационные слои, а кто-то пишет оптимальные алгоритмы. Вдобавок ко всему компонентная технология EJB ориентирована на возможность распределения второго уровня, т.е. если сервер приложений не справляется с нагрузкой, то есть возможность без единого изменения кода сервера приложений разнести его на несколько вычислительных машин. А компоненты, из которых состоит второй уровень, не будут чувствовать разницы между работой на одной вычислительной машине и на нескольких машинах.

Минусом таких систем является их направленность на крупные корпоративные решения. Если решается задача, в которой небольшое количество обращений к серверу и малый бюджет на создание системы, то, связавшись с EJB, вы будете стрелять из пушки по воробьям.

Рис. 8.3. 5-уровневая архитектура на основе EJB

352

Возникает вопрос, а зачем вообще пользоваться EJB-техно- логией? Можно построить такую же систему, например, используя C++. В этом случае получается такое же архитектурное решение, как в EJB, да и к тому же создание такой архитектуры довольно не тривиальная задача. Значительно дешевле и быстрей разобраться в правилах построения компонентов EJB-архитектуры и строить по ее принципам систему на отлаженных технологиях.

На практике можно использовать CORBA-архитектуру вместоEJB, которые работают не на очень скоростномязыкеJAVA.

На самом деле JAVA продвигает 5-уровневую архитектуру на основе EJB, показанную на рис. 8.3.

8.1.1. Сервер приложений

Самое главное в EJB это сервер приложений. Без него ничего работать не будет. Клиентские приложения будут общаться с ним через RMI или CORBA. Обычно сервер приложений предоставляет EJB-компонентам соответствующую среду. Например: хранит права доступа к компонентам (а точнее логины с паролями по доступу к серверу приложений), поддерживает RMI и CORBA-взаимодействие с ними, предоставляет JNDI сервис (сервис-именования EJB компонентов), координатор транзакций и контейнер, в котором будут храниться EJB-компоненты, сервис асинхронных сообщений JMS. Сервер приложенийизображеннарис. 8.4.

Как видно из рис. 8.4, есть компьютер, на котором работает сервер и к нему есть доступ через RMI и CORBA. Внутри самого сервера приложений работают четыре службы и контейнер.

JNDI (Java Naming Directory Interface) – эта служба по-

зволяет клиентскими приложениям находить на сервере приложений EJB компоненты по их имени. На самом деле можно взять 10 компьютеров, объединить их в сеть, установить на них серверы приложений. Но сервис JNDI включить только на одном из них. И получится, что все компоненты EJB будут доступны на одном дереве имен, а работать на разных серверах приложений. Конечно, не зря здесь применяется термин «дерево имен». Дело в том, что эта служба очень похожа на

353

древовидную файловую структуру, где есть папки (контексты) и файлы (EJB-компоненты). На всех 10 компьютерах можно запустить JNDI-сервис, но настроить их так, что какой-то один из этих сервисов будет корневым, а все остальные будут подключены к нему и на общем дереве имен будут показаны как папочки (контексты).

Рис. 8.4. Сервер приложений JMS

Transaction Service – сервис транзакций. Этот сервис предоставляет похожие услуги транзакций, как в обычных реляционных базах данных. Только в данном случае нет SQL-запросов и нет строчек базы данных, вовлеченных в транзакцию. Вместо SQL-запросов можно вызывать методы, изменяющие состояния компонентов, и как только началась транзакция, все объекты, с которыми начинают работать, будут в нее вовлечены. В конце можно откатить изменения, сделанные в объектах, либо зафиксировать их.

Security Service – сервис безопасности. Поскольку сервер приложений предоставляет удаленный доступ к EJB-компонен- там, то вообще-то очень хорошо бы этот доступ ограничить. Для этого этот сервис и нужен.

354

JMS (Java Message Service) – сервис асинхронных сооб-

щений. Есть возможность послать сообщение и не ждать подтверждения о получении или ответа. Например, когда вызывается метод удаленного компонента, то приходится ждать, пока компонент отработает и вернет назад значение. На самом деле JMS берет всю ответственность за доставку и хранения очередей сообщений, что значительно разгружает клиентские приложения. Поддерживаются механизмы: точка к точке, подписка, рассылка. Также на стороне JMS подписчик может установить фильтр и получать только те сообщения, которые его интересуют.

8.1.2. Контейнер

Он предоставляет среду, в которой могут функционировать компоненты EJB.

Каковы функции контейнера?

1.Разбор XML-описания компонента EJB (deployment descriptor) и поддержка конфигурации, описанной в этом

XML-файле.

2.Управление жизненным циклом компонента EJB. Для предоставления услуг компонента, прописанных в его интерфейсе, зарегистрированного на JNDI, необходимо создавать, уничтожать и кэшировать реализации (объекты), которые будут отвечать на запросы клиентов.

3.Разбалансировка нагрузки между реализациями (объектами), обслуживающими компонент EJB и управление пулом таких объектов.

4.Управление транзакциями в компонентах EJB. В случае

скомпонентами, которые работают с СУБД, управление транзакциями сильно связано с механизмом синхронизации состояния компонентов с состоянием СУБД.

5.Управление безопасностью доступа к компонентам. Опционально эта функция может быть отключена, и проверку прав доступа к методам вашего компонента придется реализовывать своими руками в самом компоненте.

Контейнер изображен на рис. 8.5.

355

СПИСОК РЕКОМЕНДОВАННОЙ ЛИТЕРАТУРЫ

1.Искусственный интеллект: Применение в интегрированных производственных системах / под ред. Э. Кьюсиака; пер. с англ. А.П. Фомина. – М.: Машиностроение, 1991. – 544 с.

2.Калявин В.П., Рыбаков Л.М. Надежность и диагностика электроустановок. – Йошкар-Ола: Изд-во МарГУ, 2000. – 347 с.

3.Клир Дж. Системология. Автоматизация решения системных задач: пер. с англ. – М.: Радио и связь, 1990. – 544 с.

4.Управление жизненным циклом продукции / А.Ф. Колчин

[и др.]. – М.: Анахарсис, 2002. – 304 с.

5.Громов Г.Р. Национальные информационные ресурсы: проблемы промышленной эксплуатации. – М.: Наука, 1985. – 240 с.

6.Компьютерно-интегрированные производства и CALS-техноло- гиив машиностроении / подред. д-ра техн. наук, проф. Б.И. Чер-

пакова. – М.: ГУП«ВИМИ», 1999. – 512 с.

7.Марка Д., МакГоуэн К. Методология структурного анализа и проектирования: пер. с англ. – М.: 1993. – 240 с.

8.Норенков И.Б., Кузьмик Б.К. Информационная поддержка наукоемких изделий. CALS-технологии. – М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. – 320 с.

9.Особенности внедрения ИПИ-технологий на предприятиях России / под общ. ред. д.т.н., проф. А.Н. Тихонова, д.т.н., проф. Ю.В. Полянскова. – Ульяновск: УлГУ, 2006. – 221 с.

10.Основы автоматизации производственных процессов / под ред. Ю.М. Соломенцева. – М.: Машиностроение, 1995. – 282 с.

11.Основы ИПИ-технологий: учеб. пособие / под общ. ред. д.т.н., проф. А.Н. Тихонова, д.т.н., проф. Ю.В. Полянскова. – Улья-

новск: УлГУ, 2006. – 391 с.

12.Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: учеб. / под ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2001. – 512 с.

13.Гуков Л.И., Ломако Е.И., Морозова А.В. Макетирование, проектирование и реализация диалоговых информационных систем. – М.: Финансы и статистика, 1993. – 320 с.

14.Калянов Г.Н. Консалтинг при автоматизации предприятий. –

М.: СИНТЕГ, 1997. – 316 с.

360