• 14616
  • 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
1296

Загрузка...
Loading...

Комментарии

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

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

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

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

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

Инструкция для аллергиков. Как бороться с аллергией в период обострения

Инструкция для аллергиков. Как бороться с аллергией в период обострения

Я аллергик с детства. Имею аллергию на пыльцу березы, липы, полыни (выяснил это благодаря кожным пробам), а также пищевую аллергию на горчицу. Свои проблемы знаю, однако это меня не спасло.
Romeo_17
15 авг. 2017 / 17:21
  • 38941
  • 63
СМИ – ассистент провокаторов? Как гости из соседних стран сеют раздор в Казахстане

СМИ – ассистент провокаторов? Как гости из соседних стран сеют раздор в Казахстане

Инцидент с пьяным киргизским гостем на борту Air Astana, наверное, остался бы только во внутренних сводках авиакомпании, если бы г-н Доган, не поднял громкий крик о государственном языке.
openqazaqstan
17 авг. 2017 / 14:43
  • 11496
  • 177
Казахский национализм раньше выглядел несовременно. Теперь он другой

Казахский национализм раньше выглядел несовременно. Теперь он другой

Националисты стали совсем другими. По-английски хорошо говорят, русскую классику цитируют. Очень современные, образованные, адекватные. А после Крыма в националисты уже чуть ли не любой казах готов был записаться.
Aidan_Karibzhanov
16 авг. 2017 / 16:52
Имеющий уши да услышит. Латиница касается только казахского языка

Имеющий уши да услышит. Латиница касается только казахского языка

Президент Назарбаев наконец-то разъяснил для всех, кто ещё не понял, очевидный вопрос, который всем в Казахстане очевиден. Елбасы повторил: на латиницу мы переводим казахский язык, и это не означает отказ от русского языка.
openqazaqstan
18 авг. 2017 / 16:23
  • 3285
  • 52
«Доехать до Алтын Орды» – как мошенники обманывают алматинцев

«Доехать до Алтын Орды» – как мошенники обманывают алматинцев

Из множества грустных откровений постепенно сложился перечень самых распространённых уловок охотников за нашими деньгами. В нём ожидаемо лидировали профессиональные попрошайки.
caravan_kz
16 авг. 2017 / 15:05
  • 2226
  • 4
Надо научиться видеть скрытые экономические процессы за вспышкой национального гнева

Надо научиться видеть скрытые экономические процессы за вспышкой национального гнева

При полном отсутствии бюджетного жилищного строительства, целые аулы оседают в ветхих домишках, сквозь заборы которых насмешливо возвышаются башни "коктемов", "риц карлтонов" и "есентаев".
niyazov
19 авг. 2017 / 11:16
  • 2269
  • 61
В Кокшетау строят два парка для молодёжи. Будут учтены интересы и любителей спорта

В Кокшетау строят два парка для молодёжи. Будут учтены интересы и любителей спорта

Общая площадь парка составляет 25 гектаров. На территории предусмотрено устройство прогулочных дорожек, площадок для установки аттракционов и павильонов различного назначения, цветников.
zhasakmola
17 авг. 2017 / 17:13
  • 2068
  • 1
В «Жилстройсбербанке» посоветовали не ходить в кафе, а копить на квартиру

В «Жилстройсбербанке» посоветовали не ходить в кафе, а копить на квартиру

При какой зарплате можно купить квартиру, рассказала председатель правления АО ЖССБ Ляззат Ибрагимова. Она также подчеркнула, что придется забыть, что такое вечеринки, кафе и всякие развлечения.
tala03
18 авг. 2017 / 9:55
  • 1676
  • 47
Как я перестала верить в бога: «Религия показалась мне фарсом, а бог – выдумкой»

Как я перестала верить в бога: «Религия показалась мне фарсом, а бог – выдумкой»

Первое, что зародило во мне сомнения – это стэндап-выступление Джорджа Карлина. Его монолог о религии показался мне смешным, но его было недостаточно, чтобы пошатнуть годы моей веры в бога.
DominaOmnium
18 авг. 2017 / 22:17