Копия моей статьи, напечатанной когда-то в 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 при разработке двухуровневых архитектур, их нельзя считать полноценными системами масштаба предприятия.
Более продвинутой является трёхуровневая архитектура, обычно состоящая из:
- Уровня источника данных;
- Предметного уровня (бизнес-логики);
- Уровня представления (GUI).
В классической модели построения систем масштаба предприятия трёхуровневая архитектура имеет следующее физическое разделение:
- Уровень источника данных представляет собой промышленную СУБД. Она обеспечивает централизованное структурированное хранение всех данных системы, гарантируя их целостность и непротиворечивость, а также предоставляя множество сервисов низкого уровня для: чтения данных из хранилища, сохранения данных, изменения их структуры и прочее.
- Предметный уровень разворачивается на сервере приложений, и представляет собой ядро системы. Сервер приложений обеспечивает развёртывание как непосредственно бизнес-логики системы, так и множества сервисов сторонних производителей, часто используемых системой, гарантируя её высокую степень надежности и доступности. Будучи запущенным, сервер приложений живёт самостоятельной жизнью, и может выполнять множество прикладных задач даже без участия конечного пользователя.
- Тем не менее, большинство систем предполагают активную работу пользователей, общением с которыми и занимается уровень представления, расположенный на их рабочих станциях. Основное его предназначение – создание удобного пользовательского интерфейса и обеспечение взаимодействия с сервером приложений. Существует два вида физической реализации клиентской части:
- В виде самостоятельного ПО, являющегося частью системы, и устанавливаемого на рабочей станции пользователя, так называемый «толстый клиент». После установки и запуска, он обеспечивает дальнейшее взаимодействие пользователя с бизнес-логикой на сервере приложений.
- В виде доступа из веб-браузера. Пользователь вводит в браузере строку адреса сервера приложений, который в ответ формирует в окне браузера интерфейс для дальнейшей работы. Такой подход называется «тонким клиентом», так как не требует установки на пользовательской рабочей станции частей системы. Это упрощает развёртывание системы и повсеместный доступ к ней пользователей.
В отличие от физической архитектуры системы, её логическая структура может иметь большее количество уровней. Основными целями, преследующимися при разделении на логические уровни, являются: создание и поддержание повторно используемой модели, организация проекта, независимое построение и проверка каждого уровня. Всего этого можно достигнуть и с тремя уровнями, но введение двух промежуточных уровней позволит лучше отделять бизнес-логику системы от её визуального представления и от источника данных.
Небольшое отступление. Кто-то наверняка скажет – «Что за огород мы тут городим, зачем нам столько уровней? Это всё надуманно, и только усложняет жизнь разработчика!». Попытаюсь ответить. Представим себе некую организацию, средних размеров. В ней есть с десяток отделов, в каждом из которых по десятку человек и по одному начальнику отдела. Десятью начальниками отделов руководит три директора. Директорами руководит Большой Босс, он же и владелец компании. Организация средняя – уровней получилось 4, для более крупных их наверняка должно быть больше. Попробуем убрать «лишний» уровень между Боссом и сотрудниками, пусть это будут начальники отделов. Получаем в результате три десятка сотрудников из различных отделов, приходящихся в среднем на одного директора. Каждому надо поставить специфическую для его должности задачу, проконтролировать её выполнение, решить периодически возникающие у него проблемы и т.д. и т.п. Даже если и существуют директора, способные одинаково хорошо напрямую управлять одновременно десятком инженеров, десятком менеджеров по продажам и десятком бухгалтеров, то при всём этом стратегическими задачами организации он просто физически управлять уже не сможет. А без стратегического управления получится что-то вроде автомобиля, у которого отлично работают все системы, но никак друг от друга не зависят: одно колесо едет влево, другое вправо – колеса сами по себе исправны, да только толку с этого? То же самое, но на другом уровне произойдёт, если убрать уровень директоров. Большому Боссу ясны стратегические задачи, но пока он будет доносить их до каждого начальника отдела, помогать им координировать совместные действия и т.д., может оказаться, что продукция компании уже не востребована, или хитрые конкуренты захватили весь рынок, и прочие глобальные напасти. Возвращаясь к примеру автомобиля: он прекрасно слушается руля, резво набирает скорость и т.д., одна лишь проблема – дёргая за десятки управляющих рычажков, у водителя нет времени понять куда он собственно едет.
Классикой логической структуры системы масштаба предприятия можно считать пятиуровневую структуру, состоящую из (по тексту выделены два новых уровня):
- Уровня источника данных (В J2EE реализуется такими технологиями, как JDBC, JMS, и т.д.). Я ставлю этот уровень на первое место с точки зрения разработчика, т.к. в большинстве случаев, прежде чем ваша система сделает своё первое полезное действие, в ней должна появиться какая-то структура данных. Грамотно разработанная схема хранения данных отрезает немалую часть «путей налево» на этапе разработки ПО. В большинстве случаев для хранения и получения данных используются реляционные СУБД, в комплекте поставки которых обычно есть драйверы, реализующие спецификацию JDBC. Для работы с источником данных, в составе сервера приложений обычно разворачивается соответствующий сервис. Обычно, для его подключения к конкретной СУБД, не требуется много усилий: достаточно добавить на сервер файлы драйвера, реализующего спецификацию JDBC и указать несколько свойств в конфигурационном файле. После этого, система может создавать и выполнять запросы к источнику данных на независимом от разработчиков языке структурированных запросов (Structured Query Language - SQL). В некоторых случаях, источником данных могут являться другие корпоративные системы, для взаимодействия с ними в стандарте J2EE есть такие спецификации, как служба сообщений JMS (Java Message Service), архитектура коннекторов J2C (Java2 Connector Architecture), а также веб-сервисы.
- Уровня сопоставления данных (Entity EJB, Mapper objects…). Отделяя предметную логику от операций чтения/сохранения данных, и предоставляя объектно-ориентированный доступ к хранимым данным, путём отображения (mapping) объектов предметной логики на структуру источника данных, этот уровень делает код разрабатываемой системы намного «чище» и яснее для понимания, а также снижает зависимость бизнес-логики от источника данных. В системе создаются объекты, имеющие свойства, используемые бизнес-логикой. Операции их чтения/сохранения осуществляются прозрачно для разработчика: если при отсутствии данного уровня, при сохранении объекта требуется последовательно указать системе, как сохранить каждое свойство объекта, то с использованием уровня сопоставления разработчик бизнес-логики просто «говорит» системе – «сохрани объект» (то же касается и чтения объектов). Существуют различные реализации этого уровня, одной из самых известных является бесплатно распространяемая технология Hibernate. Основной её принцип: создание объектов бизнес-логики в виде обычных и удобных в использовании классов языка Java (они так же называются Plain Old Java Object - POJO), и описания их сопоставления источнику данных в отдельных файлах в формате XML. С появлением в Java 5 механизма аннотаций, в Hibernate была добавлена возможность не использовать отдельные описания в XML-файлах, указывая сопоставление источнику данных непосредственно в самом классе.
- Уровня бизнес-логики (Session EJBs, JavaBeans…). Это уровень и есть, собственно говоря, наша система. Не буду вдаваться в принципы построения непосредственно бизнес-логики приложений, статья не совсем об этом. Для реализации этого уровня в серверных компонентах, в J2EE предусмотрена спецификация Enterprise JavaBeans (EJB). Можно реализовывать бизнес-логику как с использованием EJB, так и без неё, при помощи стандартных POJO. Чем написание бизнес-логики при помощи POJO отличается от её создания в EJB? Сервер приложений в своём составе содержит EJB-контейнер, в котором разворачиваются классы, реализованные как EJB. Для развёрнутых EJB, контейнер может обеспечивать следующие сервисы:
- поддержка сохранности данных (persistence);
- поддержка распределённых транзакций
- поддержка конкурентного изменения данных и многопоточность
- поддержка событий
- поддержка именования и каталогов (JNDI)
- безопасность и ограничение доступа к данным
- поддержка автоматизированной установки на сервер приложений
- удалённый доступ
Исходя из списка сервисов, можно понять, что возможности EJB выходят далеко за рамки простого содержания в себе бизнес-логики. Это подтверждается, например, в описании следующего уровня, в котором EJB может использоваться предоставляя сервис «удалённый доступ».
- Уровня контроллера/медиатора (Servlets, Struts, JavaBeans, Message-Driven Beans…). Отделяя способ взаимодействия пользователя с предметной логикой, этот уровень даёт возможность повторного использования бизнес-логики различными представлениями. Это даёт возможность обращаться к одним и тем же функциям бизнес-логики как из полноценного «толстого клиента», так и из более бедного, но более доступного веб-интерфейса браузера или даже с вашего КПК, стоя в автомобильной пробке. Реализующие этот уровень технологии довольно разнообразны и слишком ёмкие для того, чтобы описывать их здесь; скажу лишь что он является связующим звеном между пользователем и системой, и физически обычно распределён между обоими соседними уровнями (бизнес-логикой и представлением). Также следует упомянуть, что пользователем системы может являться другая система, что обосновывает упоминание на этом уровне спецификации Message-Driven Beans – компонент, управляемых сообщениями.
- Уровня представления (Swing GUI, HTML, JSP, JSF, XSLT…). Логическое определение этого уровня схоже с его физическим описанием (см. выше). Что касается реализующих его в J2EE технологий, то:
- «толстый клиент» обычно реализуется с использованием Swing, взаимодействуя с сервером приложений посредством JavaBeans, выступающих в качестве контроллера/медиатора. При этом осуществляется взаимодействие клиентской среды исполнения Java со средой, запущенной на сервере, обычно посредством протокола TCP/IP.
- большинство остальных технологий реализуют «тонких клиентов», взаимодействуя с сервером приложений обычно посредством протокола HTTP. Это отдельная обширная тема для обсуждений, упомяну только появление не так давно и бурное развитие технологии AJAX (Asynchronous Javascript and XML), позволяющей пользователю обмениваться данными с сервером без перезагрузки страницы целиком.
В небольших проектах всё же можно обойтись без каких-либо из вышеуказанных уровней, вплоть до возврата к двухуровневой архитектуре, особенно если есть уверенность в том, что проект не будет развиваться и расширяться. Для более крупных проектов каждый уровень заметно облегчает жизнь, особенно на этапах поддержки и дальнейшего расширения системы.
К сожалению, описываемые технологии затронуты очень поверхностно, так как в пределах одной статьи невозможно дать даже краткое резюме по каждой из них. Основной темой статьи было описание вертикальной архитектуры систем масштаба предприятия. Также существует и горизонтальная структура, заметно приближающая нас непосредственно к процессам разработки программного обеспечения, о чём мы и поговорим в следующей статье.