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

Часть 1

Автор: Евгений Игумнов
Геокад Плюс (Новосибирск)

Введение

Думаю, расхваливать то, что будет написано мной сразу не стоит. Лучше сказать чего я постараюсь не написать. Если Вы хотите увидеть здесь учебник по которому можно научится основам EJB, то лучше Вам почитать книжки типа Corba за 14 дней. Если Вы ждете моих вздохов по перспективности и крутости технологии EJB, то Вам лучше почитать обзоры популярных компьютерных журналов. Если Вы ожидаете найти здесь обилие исходных примеров, да еще что бы они компилировались и работали,то Вам лучше почитать Manual от любого поставщика коммерческой или некоммерческой версии EJB сервера. В общем получается, что не совсем понятно, для кого я это все буду писать. Не знаю, как даже охарактеризовать моего потенциального читателя. Думаю, что я пишу это для себя самого. Но не для себя в данный момент, а для себя несколько месяцев назад. Дело в том, что не так давно я писал линейные программы без объектно-ориентированного подхода. Хотя прекрасно знал об ООП, но не использовал, так как считал это неудобным. Мне, к сожалению, пришлось решать несколько довольно сложных задач. И решал я их без ООП. Решал вполне успешно. Но вот когда пришло время модернизации разработанных систем... Я был просто подавлен. И тут меня судьба свела с человеком, который мне показал способы применения ООП: отображение объектов в БД, коллекции объектов и т.д. Имя этого человека Сергей Резинкин. Выражаю ему благодарность. Если бы не он... Другими словами мне нужен был толчок в верном направлении. Я стал интересоваться UML, потом CORBA, потом вышел на EJB и многое другое. Так вот я хочу Вам дать толчок в верном направлении. Я обозначу Вам путь. Многое здесь Вы, возможно, не воспримите по причине краткости изложения или отсутствия опыта, который бы позволил верно воспринять некоторые вещи. Надеюсь Вас задеть, что бы Вы сами дальше начали копать в этом направлении.

Архитектура технологии 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.

Copyright © 2001 Eugene Igumnov. Все права защищены.
Домашняя страничка: http://manager.olc.ru
30.04.2001

Содержание | Вперед