• 14216
  • 120
  • 7
Нравится блог?
Подписывайтесь!

Расцвет Enterprise Java, продолжение

Копия моей статьи, напечатанной когда-то в Digital Kazakhstan. Эта версия uncensored, в журнале пришлось на 30% сократить...

В прошлой статье мы познакомились поверхностно с языком Java и технологией J2EE (Java 2 Enterprise Edition), предназначенной для создания программного обеспечения уровня предприятия. Были затронуты темы кроссплатформенности, бесплатности распространения платформы Java, и множества сопутствующих технологий; обозначены семейства технологий Java - J2SE (Java 2 Standard Editon), J2ME (Java 2 Micro Edition), J2EE (Java 2 Enterprise Editon); также мы рассмотрели общие принципы и смысл существования спецификаций J2EE. В этой статье мне бы хотелось «копнуть поглубже» архитектуру копоративных систем, и применяемых при их построении J2EE-технологий.

Абсолютное большинство информационных систем предприятий предназначены для хранения и модификации данных: отдел кадров ведёт сведения по сотрудникам, бухгалтерия работает с финансовыми документами и проводками, кладовщик ведёт учёт товара и т.д. Данные хранятся в СУБД (Система управления базами данных), обычно представляющей собой сугубо техническое программное обеспечение, одним только своим названием приводящем в трепет вышеупомянутых лиц (скажите на ухо бухгалтеру зловещим шёпотом «ORACLE!» или «INFORMIX!!!» и будьте уверены – премии вам в этом месяце не видать). Создаётся впечатление, что СУБД намерено создают таким образом, чтобы непосвящённый никогда не смог бы понять смысл их существования и боже упаси – каким-то образом с пользой применить. Чтобы как-то уберечь наших кадровиков и бухгалтеров от всего этого ужаса и создаются ПРОГРАММЫ (более научно – прикладное программное обеспечение). Они рисуют красивые таблички и кнопочки, нажимая которые можно вносить данные в СУБД, даже не осознавая сам факт её существования.
Если мы напишем программу, которая, будучи запущенной конечным пользователем будет обращаться непосредственно к СУБД, то мы получим так называемую двухуровневую архитектуру приложения, состоящую из уровня представления данных и уровня доступа к данным. В таких приложениях связаны воедино интерфейс пользователя (GUI – Graphical User Interface), правила предметной логики и функционал обращений к базе данных. Бизнес-логика зачастую хаотично разбросана по исходному коду, смешавшись с описанием GUI. Нередко интерфейс создаёт что-то вроде моста к СУБД, давая пользователю практически прямой доступ на редактирование записей в таблицах базы данных. В таких условиях нелегко применять принципы повторного использования, и сложно поддерживать ранее разработанное ПО, особенно если разрабатывал его кто-то другой. Для разработки двухуровневого приложения в Java могут использоваться технологии Swing и JDBC. Технология Java Swing предназначена для разработки интерфейса пользователя и входит в состав J2SE. JDBC (Java Database Connectivity) в свою очередь является одной и составных частей J2EE и описывает стандартные для Java принципы работы с СУБД. Несмотря на возможность применения технологий J2EE при разработке двухуровневых архитектур, их нельзя считать полноценными системами масштаба предприятия.

Более продвинутой является трёхуровневая архитектура, обычно состоящая из:

  1. Уровня источника данных;
  2. Предметного уровня (бизнес-логики);
  3. Уровня представления (GUI).

В классической модели построения систем масштаба предприятия трёхуровневая архитектура имеет следующее физическое разделение:

  1. Уровень источника данных представляет собой промышленную СУБД. Она обеспечивает централизованное структурированное хранение всех данных системы, гарантируя их целостность и непротиворечивость, а также предоставляя множество сервисов низкого уровня для: чтения данных из хранилища, сохранения данных, изменения их структуры и прочее.
  2. Предметный уровень разворачивается на сервере приложений, и представляет собой ядро системы. Сервер приложений обеспечивает развёртывание как непосредственно бизнес-логики системы, так и множества сервисов сторонних производителей, часто используемых системой, гарантируя её высокую степень надежности и доступности. Будучи запущенным, сервер приложений живёт самостоятельной жизнью, и может выполнять множество прикладных задач даже без участия конечного пользователя.
  3. Тем не менее, большинство систем предполагают активную работу пользователей, общением с которыми и занимается уровень представления, расположенный на их рабочих станциях. Основное его предназначение – создание удобного пользовательского интерфейса и обеспечение взаимодействия с сервером приложений. Существует два вида физической реализации клиентской части:
    • В виде самостоятельного ПО, являющегося частью системы, и устанавливаемого на рабочей станции пользователя, так называемый «толстый клиент». После установки и запуска, он обеспечивает дальнейшее взаимодействие пользователя с бизнес-логикой на сервере приложений.
    • В виде доступа из веб-браузера. Пользователь вводит в браузере строку адреса сервера приложений, который в ответ формирует в окне браузера интерфейс для дальнейшей работы. Такой подход называется «тонким клиентом», так как не требует установки на пользовательской рабочей станции частей системы. Это упрощает развёртывание системы и повсеместный доступ к ней пользователей.

В отличие от физической архитектуры системы, её логическая структура может иметь большее количество уровней. Основными целями, преследующимися при разделении на логические уровни, являются: создание и поддержание повторно используемой модели, организация проекта, независимое построение и проверка каждого уровня. Всего этого можно достигнуть и с тремя уровнями, но введение двух промежуточных уровней позволит лучше отделять бизнес-логику системы от её визуального представления и от источника данных.

Небольшое отступление. Кто-то наверняка скажет – «Что за огород мы тут городим, зачем нам столько уровней? Это всё надуманно, и только усложняет жизнь разработчика!». Попытаюсь ответить. Представим себе некую организацию, средних размеров. В ней есть с десяток отделов, в каждом из которых по десятку человек и по одному начальнику отдела. Десятью начальниками отделов руководит три директора. Директорами руководит Большой Босс, он же и владелец компании. Организация средняя – уровней получилось 4, для более крупных их наверняка должно быть больше. Попробуем убрать «лишний» уровень между Боссом и сотрудниками, пусть это будут начальники отделов. Получаем в результате три десятка сотрудников из различных отделов, приходящихся в среднем на одного директора. Каждому надо поставить специфическую для его должности задачу, проконтролировать её выполнение, решить периодически возникающие у него проблемы и т.д. и т.п. Даже если и существуют директора, способные одинаково хорошо напрямую управлять одновременно десятком инженеров, десятком менеджеров по продажам и десятком бухгалтеров, то при всём этом стратегическими задачами организации он просто физически управлять уже не сможет. А без стратегического управления получится что-то вроде автомобиля, у которого отлично работают все системы, но никак друг от друга не зависят: одно колесо едет влево, другое вправо – колеса сами по себе исправны, да только толку с этого? То же самое, но на другом уровне произойдёт, если убрать уровень директоров. Большому Боссу ясны стратегические задачи, но пока он будет доносить их до каждого начальника отдела, помогать им координировать совместные действия и т.д., может оказаться, что продукция компании уже не востребована, или хитрые конкуренты захватили весь рынок, и прочие глобальные напасти. Возвращаясь к примеру автомобиля: он прекрасно слушается руля, резво набирает скорость и т.д., одна лишь проблема – дёргая за десятки управляющих рычажков, у водителя нет времени понять куда он собственно едет.

Классикой логической структуры системы масштаба предприятия можно считать пятиуровневую структуру, состоящую из (по тексту выделены два новых уровня):

  1. Уровня источника данных (В J2EE реализуется такими технологиями, как JDBC, JMS, и т.д.). Я ставлю этот уровень на первое место с точки зрения разработчика, т.к. в большинстве случаев, прежде чем ваша система сделает своё первое полезное действие, в ней должна появиться какая-то структура данных. Грамотно разработанная схема хранения данных отрезает немалую часть «путей налево» на этапе разработки ПО. В большинстве случаев для хранения и получения данных используются реляционные СУБД, в комплекте поставки которых обычно есть драйверы, реализующие спецификацию JDBC. Для работы с источником данных, в составе сервера приложений обычно разворачивается соответствующий сервис. Обычно, для его подключения к конкретной СУБД, не требуется много усилий: достаточно добавить на сервер файлы драйвера, реализующего спецификацию JDBC и указать несколько свойств в конфигурационном файле. После этого, система может создавать и выполнять запросы к источнику данных на независимом от разработчиков языке структурированных запросов (Structured Query Language - SQL). В некоторых случаях, источником данных могут являться другие корпоративные системы, для взаимодействия с ними в стандарте J2EE есть такие спецификации, как служба сообщений JMS (Java Message Service), архитектура коннекторов J2C (Java2 Connector Architecture), а также веб-сервисы.
  2. Уровня сопоставления данных (Entity EJB, Mapper objects…). Отделяя предметную логику от операций чтения/сохранения данных, и предоставляя объектно-ориентированный доступ к хранимым данным, путём отображения (mapping) объектов предметной логики на структуру источника данных, этот уровень делает код разрабатываемой системы намного «чище» и яснее для понимания, а также снижает зависимость бизнес-логики от источника данных. В системе создаются объекты, имеющие свойства, используемые бизнес-логикой. Операции их чтения/сохранения осуществляются прозрачно для разработчика: если при отсутствии данного уровня, при сохранении объекта требуется последовательно указать системе, как сохранить каждое свойство объекта, то с использованием уровня сопоставления разработчик бизнес-логики просто «говорит» системе – «сохрани объект» (то же касается и чтения объектов). Существуют различные реализации этого уровня, одной из самых известных является бесплатно распространяемая технология Hibernate. Основной её принцип: создание объектов бизнес-логики в виде обычных и удобных в использовании классов языка Java (они так же называются Plain Old Java Object - POJO), и описания их сопоставления источнику данных в отдельных файлах в формате XML. С появлением в Java 5 механизма аннотаций, в Hibernate была добавлена возможность не использовать отдельные описания в XML-файлах, указывая сопоставление источнику данных непосредственно в самом классе.
  3. Уровня бизнес-логики (Session EJBs, JavaBeans…). Это уровень и есть, собственно говоря, наша система. Не буду вдаваться в принципы построения непосредственно бизнес-логики приложений, статья не совсем об этом. Для реализации этого уровня в серверных компонентах, в J2EE предусмотрена спецификация Enterprise JavaBeans (EJB). Можно реализовывать бизнес-логику как с использованием EJB, так и без неё, при помощи стандартных POJO. Чем написание бизнес-логики при помощи POJO отличается от её создания в EJB? Сервер приложений в своём составе содержит EJB-контейнер, в котором разворачиваются классы, реализованные как EJB. Для развёрнутых EJB, контейнер может обеспечивать следующие сервисы:
    • поддержка сохранности данных (persistence);
    • поддержка распределённых транзакций
    • поддержка конкурентного изменения данных и многопоточность
    • поддержка событий
    • поддержка именования и каталогов (JNDI)
    • безопасность и ограничение доступа к данным
    • поддержка автоматизированной установки на сервер приложений
    • удалённый доступ

    Исходя из списка сервисов, можно понять, что возможности EJB выходят далеко за рамки простого содержания в себе бизнес-логики. Это подтверждается, например, в описании следующего уровня, в котором EJB может использоваться предоставляя сервис «удалённый доступ».

  4. Уровня контроллера/медиатора (Servlets, Struts, JavaBeans, Message-Driven Beans…). Отделяя способ взаимодействия пользователя с предметной логикой, этот уровень даёт возможность повторного использования бизнес-логики различными представлениями. Это даёт возможность обращаться к одним и тем же функциям бизнес-логики как из полноценного «толстого клиента», так и из более бедного, но более доступного веб-интерфейса браузера или даже с вашего КПК, стоя в автомобильной пробке. Реализующие этот уровень технологии довольно разнообразны и слишком ёмкие для того, чтобы описывать их здесь; скажу лишь что он является связующим звеном между пользователем и системой, и физически обычно распределён между обоими соседними уровнями (бизнес-логикой и представлением). Также следует упомянуть, что пользователем системы может являться другая система, что обосновывает упоминание на этом уровне спецификации Message-Driven Beans – компонент, управляемых сообщениями.
  5. Уровня представления (Swing GUI, HTML, JSP, JSF, XSLT…). Логическое определение этого уровня схоже с его физическим описанием (см. выше). Что касается реализующих его в J2EE технологий, то:
    • «толстый клиент» обычно реализуется с использованием Swing, взаимодействуя с сервером приложений посредством JavaBeans, выступающих в качестве контроллера/медиатора. При этом осуществляется взаимодействие клиентской среды исполнения Java со средой, запущенной на сервере, обычно посредством протокола TCP/IP.
    • большинство остальных технологий реализуют «тонких клиентов», взаимодействуя с сервером приложений обычно посредством протокола HTTP. Это отдельная обширная тема для обсуждений, упомяну только появление не так давно и бурное развитие технологии AJAX (Asynchronous Javascript and XML), позволяющей пользователю обмениваться данными с сервером без перезагрузки страницы целиком.

В небольших проектах всё же можно обойтись без каких-либо из вышеуказанных уровней, вплоть до возврата к двухуровневой архитектуре, особенно если есть уверенность в том, что проект не будет развиваться и расширяться. Для более крупных проектов каждый уровень заметно облегчает жизнь, особенно на этапах поддержки и дальнейшего расширения системы.

К сожалению, описываемые технологии затронуты очень поверхностно, так как в пределах одной статьи невозможно дать даже краткое резюме по каждой из них. Основной темой статьи было описание вертикальной архитектуры систем масштаба предприятия. Также существует и горизонтальная структура, заметно приближающая нас непосредственно к процессам разработки программного обеспечения, о чём мы и поговорим в следующей статье.

vovan_sidorytch
24 ноября 2009, 14:35
1272

Loading...

Комментарии

Интересная статья, будет ли продолжение?
Спасибо. Вообще, в журнале мои статьи принимали с удовольствием, и просили писать ещё; я даже план третьей статьи начинал набрасывать, но как-то остыл, забросил... Вполне возможно, что я напишу третью статью, но врядли в ближайшее время...

Оставьте свой комментарий

Спасибо за открытие блога в Yvision.kz! Чтобы убедиться в отсутствии спама, все комментарии новых пользователей проходят премодерацию. Соблюдение правил нашей блог-платформы ускорит ваш переход в категорию надежных пользователей, не нуждающихся в премодерации. Обязательно прочтите наши правила по указанной ссылке: Правила

Также можно нажать Ctrl+Enter

Популярные посты

Исламская ипотека в Казахстане: в этом году выйдет на розничный рынок

Исламская ипотека в Казахстане: в этом году выйдет на розничный рынок

Многие клиенты, вздыхая о харамном ссудном проценте местных банков, сокрушались по поводу отсутствия у нас халяльного кредитования. Поддержка исламского банкинга на уровне МФЦА есть...
DanaJarlygapova
24 марта 2017 / 18:28
  • 20665
  • 59
Компания LG Electronics открыла предзаказ на новый флагман LG G6

Компания LG Electronics открыла предзаказ на новый флагман LG G6

LG Electronics объявляет о начале предварительного заказа онлайн на новый смартфон LG G6. Оформить предзаказ можно на сайтах магазинов электроники до 16 апреля 2017 года.
LG Electronics
24 марта 2017 / 14:20
  • 5185
  • 0
Беременность по-американски. Никто не ждет до 40 дней, с малышом гуляют с первого дня

Беременность по-американски. Никто не ждет до 40 дней, с малышом гуляют с первого дня

Мои волшебные 9 месяцев протекали в новой среде и далеко от всех родственников и подружек. Никто из моих знакомых в США на тот момент не успел обзавестись малышом, поэтому мне не с кем было...
Zarema_
23 марта 2017 / 9:25
  • 5177
  • 16
Страну, где так строят дороги, победить невозможно!

Страну, где так строят дороги, победить невозможно!

Шестиминутный ролик про строительство автомобильной дороги в США - это как острый нож в пузо нашим чиновникам. Они же подавятся бешбармаком, увидев его! Похлеще любого пропагандистского фильма...
Timur_Tregulov
24 марта 2017 / 11:26
  • 4645
  • 38
Это вам не Дисней. Реальный прототип «Красавицы и Чудовища»

Это вам не Дисней. Реальный прототип «Красавицы и Чудовища»

Многие уверенны на 100%, что сказка «Красавица и Чудовище» - это интересная выдумка ее создателей. Однако, действия, происходящие в мультфильме и фильме, имели место в истории, и у главных героев...
Naomi_K
24 марта 2017 / 18:42
  • 4847
  • 34
Семь причин почему вам надо перестать откладывать переезд за границу

Семь причин почему вам надо перестать откладывать переезд за границу

Вы думаете о переезде за границу, но постоянно откладываете дату, потому что вас беспокоит тысяча мелочей, которые могут пойти не так? У меня есть семь причин, почему пора перестать мотать нервы...
Lesch
24 марта 2017 / 17:50
  • 3786
  • 14
Гонения на «Свидетелей Иеговы». Кому это выгодно?

Гонения на «Свидетелей Иеговы». Кому это выгодно?

Я не "Свидетель Иеговы". Мне приходилось защищать в судах и кришнаитов и коммунистов, хотя я и не разделяю их убеждений. Я защищаю свободу совести. Сегодня "Свидетели Иеговы", завтра,- каждый из вас.
nasreddin
25 марта 2017 / 17:18
  • 3901
  • 47
Страна обыденной роскоши: Ташкент-Самарканд-Бухара

Страна обыденной роскоши: Ташкент-Самарканд-Бухара

Узбекистан - это страна, где роскошь стала обыденностью. Это и повсеместный зелёный крупнолистовой чай. И вкусная натуральная еда с минимумом специй. И то, что дети играют среди исторических памятников.
MadinaR
25 марта 2017 / 10:37
  • 3153
  • 59
Посчитав сколько я смогу сэкономить на еде, я понял, что это очень приличная сумма

Посчитав сколько я смогу сэкономить на еде, я понял, что это очень приличная сумма

Именно сейчас я начинаю понимать, как себя чувствуют иногородние студенты, которые живут общежитиях у нас в Алматы. Я не говорю, что они живут плохо, но многие из них рассчитывают только на свои...
noyanovmyras
23 марта 2017 / 0:18
  • 3491
  • 62