Распределенные
многоуровневые приложения
Платформа J2EE использует многоуровневую
распределенную модель приложения. Логика
приложения делится на компоненты в
соответствии с функциями, и разные
компоненты приложения, составляющие
приложение J2EE, устанавливаются на
разных машинах в зависимости
от того, к какому слою в многоуровневой
среде J2EE этот компонент относится.Рис
1-1 показывает два многоуровневых
приложения J2EE, разделенных по слоям, описываемым
в следующем списке. Части приложения
J2EE, показанные на Рис.
1-1, представлены в Компоненты
J2EE.
- Компоненты клиентского слоя, выполняющиеся на клиентской машине.
- Компоненты Web-слоя, выполняющиеся на сервере J2EE.
- Компоненты бизнес-слоя, выполняющиеся на сервере J2EE.
- Программное обеспечение слоя Enterprise information system (EIS), выполняющееся на сервере EIS.
Хотя приложение J2EE может
состоять из трех или четырех уровней,
показанных на Рис.
1-1, многоуровневые приложения
J2EE обычно рассматриваются как 3-уровневые,
потому что они распределяются между тремя
разными местами: клиентская машина, машина-сервер
J2EE и база данных или "унаследованная"
машина на верхнем конце. Трехуровневые
приложения, выполняющиеся таким образом,
расширяют стандартную 2-уровневую клиент-серверную
модель помещением сервера многоуровневых
приложений между клиентским приложением
и сервером баз данных.
Рис. 1-1 Многоуровневые
приложения
Компоненты
J2EE
Приложения J2EE делаются из компонентов. Компонент J2EE -
это самостоятельная функциональная программная
единица, которая собирается в приложение
J2EE вместе с относящимися к ней классами
и файлами и которая сообщается с другими
компонентами. Спецификация J2EE определяет
следующие компоненты J2EE:
- Прикладные клиенты и аплеты являются компонентами, выполняемыми на клиенте
- Компоненты технологий сервлетов Java Servlet и JavaServer Pages
(JSP
) являются Web-компонентами, которые выполняются на сервере.
- Компоненты Enterprise JavaBeans
(EJB
) (корпоративные бины) являются бизнес-компонентами, которые выполняются на сервере.
Компоненты J2EE пишутся на
языке программирования Java и компилируются
так же, как и любые программы
на этом языке. Разница между компонентами
J2EE и "стандартными" классами Java состоит
в том, что компоненты J2EE собираются
в приложение J2EE, проверяются на
формат и на соответствие спецификациям
J2EE, и внедряются в продукт, где
они выполняются и управляются
сервером J2EE.
Клиенты
J2EE
Клиентами J2EE может быть
Web-клиент или клиент-приложение.
Web-клиенты
Web-клиент состоит из
двух частей: динамические Web-страницы,
содержащие различные типы языков
разметки (HTML, XML и т.п.), которые генерируются
Web-компонентами, выполняющимися на
Web-уровне, и Web-браузер, который
представляет страницы, полученные
с сервера.
Web-клиент иногда называется тонким клиентом.
Эти клиенты обычно не делают таких вещей,
как запросы к базе данных, выполнение
сложных бизнес-правил или соединение
с "унаследованными" приложениями.
Если вы используете тонкого клиента,
то тяжеловесные опрерации, подобные этим,
переносятся на корпоративные бины, выполняющиеся
на сервере J2EE, где они могут повысить
безопасность, скорость, полезность и
надежность серверных технологий J2EE.
Аплеты
Web-страница, полученная с
Web-уровня может включать в
себя встроенный аплет. Аплет
является маленьким клиентским
приложением, написанным на языке
Java, которое выполняется в Виртуальной
Машине Java, установленной в браузере.
Однако клиентская система при
этом должна иметь подключение
Java и, возможно, файл политики
безопасности для того, чтобы
аплет успешно выполнялся в
Web-браузере.
Web-компоненты являются
предпочтительным API для создания Web-клиентских
программ, потому что для клиентской
системы при этом не требуется
подключения или файлов политики
безопасности. Также Web-компоненты
позволяют сделать более ясным
и более модульным проект приложения,
потому что они обеспечивают
путь для отделения прикладного
программирования от проектирования
Web-страницы. Персонал, занимающийся
проектированием Web-страниц, не
нуждается в понимании синтаксиса
языка Java, чтобы делать свою
работу.
Клиенты
- приложения
Клиенты-приложения J2EE выполняются
на клиентской машине и поддерживают
пользователей, которые обрабатывают
задачи, требующие более богатого
пользовательского интерфейса, чем
тот, который может быть обеспечен
языком разметки. Это обычно графический
интерфейс (GUI), создаваемый API Swing или Abstract
Window Toolkit (AWT), но возможен также и
интерфейс командной строки.
Клиенты-приложения напрямую
обращаются к корпоративным бинам
в бизнес-слое. Однако, если требования
приложения оправдывают это, клиент-приложение
J2EE может открывать HTTP-соединение для
установления взаимодействия с сервлетом,
выполняющимся в Web-слое.
Компонентная
архитектура JavaBeans
Сервер и клиент должны
также включать компоненты, базирующиеся
на компонентной архитектуре JavaBeans (компоненты
JavaBeans) для управления потоком данных
между клиентом-приложением или
аплетом и компонентами, выполняющимися
на сервере J2EE, или между серверными
компонентами и базой данных. Компоненты
JavaBeans не рассматриваются спецификациями
J2EE как компоненты J2EE.
Компоненты JavaBeans имеют переменные
экземпляра и методы get и set для доступа
к данным в переменных экземпляра. Компоненты
JavaBeans, используемые таким способом, являются
обычно простыми в проектировании и реализации,
но должны соответствовать соглашениям
именования и проектирования, принятым
в компонентной архитектуре JavaBeans.
Серверные
взаимодействия J2EE
Рис.
1-2 показывает различные элементы,
которые могут составлять клиентский
слой. Клиент взаимодействует с бизнес-слоем,
выполняющимся на сервере J2EE, либо непосредственно,
либо, как в случае, когда клиент выполняется
на браузере, через страницы JSP или сервлеты,
выполняющиеся в Web-слое.
Ваше приложение J2EE использует
тонкого клиента на базе браузера
или толстого клиента-приложение. При
принятии решения, какого из клиентов
использовать, вы должны сделать сознательный
выбор между сохранением функциональности
на клиенте, поближе к пользователю
(толстый клиент), и передачей
как можно большей функциональности
на сервер (тонкий клиент). Чем больше
функциональности вы перегрузите на
сервер, тем легче распространять,
разворачивать и обслуживать
приложение; однако, сохранение большей
функциональности на клиенте может
быть выбрано для того, чтобы лучше
использовать опыт пользователя.
Рис. 1-2 Серверные
взаимодействия
Web-компоненты
J2EE Web-компоненты могут
быть сервлетами или страницами
JSP. Сервлеты являются
классами языка Java, которые динамически
обрабатывают запросы и конструируют
ответы.Страницы JSP являются
текстовыми документами, которые выполняются
как сервлеты, но обеспечивают более естественный
подход к созданию статического содержания.
Статические HTML-страницы и
аплеты связываются с Web-компонентами
при сборке приложения, но они не
рассматриваются как Web-компоненты
спецификациями J2EE. Серверные обслуживающие
классы которые также могут связываться
с Web-компонентами, как и HTML-страницы,
не рассматриваются как Web-компоненты.
Подобно клиентскому слою,
как показано на Рис.
1-3, Web-слой может включать в себя
компоненты JavaBeans для обслуживания пользовательского
ввода и пересылки ввода для обработки
корпоративным бинам, выполняемым в бизнес-слое.
Бизнес-компоненты
Код, который предназначен
для решения задач и удовлетворения
нужд определенной прикладной области,
такой как банковское дело, торговля
или финансы, выполняется корпоративными
бинами, выполняющимися в бизнес-слое. Рис.
1-4 показывает, как корпоративный
бин получает данные от клиентских программ,
обрабатывает их (если необходимо), и посылает
их на уровень корпоративной информационной
системы для сохранения. Корпоративный
бин также получает данные из хранилища,
обрабатывает их (если необходимо), и посылает
их обратно клиентской программе.
Рис. 1-3 Web-слой и
приложение J2EE
Рис. 1-4 Слои бизнеса
и EIS
Есть три вида корпоративных
бинов: бины сеанса, бины сущности и
бины, управляемые сообщениями. Бин сеанса представляет
кратковременное взаимодействие с клиентом.
Когда клиент заканчивает выполнение,
бин сеанса и его данные теряются. Напротив, бин сущности представляет
постоянно существующие данные, сохраненные
в строке таблицы базы данных. Если завершается
клиент или выключается сервер, базовые
службы обеспечивают, что бин сущности
сохранится.
Бин, управляемый
событием, соединяет в себе свойства бина
сеанса и слушателя сообщений Java Message Service
("JMS"), позволяя бизнес-компоненту
асинхронно получать сообщения JMS. Этот
учебник описывает бины сущности и бины
сеанса. Информацию о бинах, управляемых
событиями, см. в The Java Message Service Tutorial,
доступном в:
Уровень
корпоративной информационной системы
Слой корпоративной информационной
системы работает с программным
обеспечением корпоративной системы
и включает в себя системы инфраструктуры
предприятия, такие как планирование
ресурсов предприятия (ERP), обработка
транзакций на мейнфрейме, системы
баз данных и другие "унаследованные"
информационные системы. Компоненты приложения
J2EE могут иметь доступ к корпоративным
информационным системам, например, для
соединения с базой данных.
Лекция 6. Архитектура
распределенных приложений J2EE.
Общие принципы построения
распределенных систем
Построение распределенных систем
высокого качества является одной из
наиболее сложных задач по разработке
ПО. Технология J2EE была создана как
раз для того, чтобы сделать
разработку наиболее часто встречающегося
вида распределенных систем — так
называемых бизнес приложений, поддерживающих
решение наиболее часто встречающихся
бизнес-задач — достаточно простой
и доступной любому программисту.
Чтобы лучше понять принципы J2EE,
стоит разобраться в основных
проблемах, возникающих при построении
распределенных систем и в том, как
эти проблемы решаются с использованием
данной технологии.
Основная задача, которую пытаются решить
с помощью распределенных систем — обеспечение
максимально простого доступа как можно
большему числу пользователей ко всем
ресурсам, которые могут им понадобиться.
При этом важными свойствами такой системы
являются следующие.
-
Прозрачность.
Прозрачность проявляется как способность системы скрыть от пользователя физическое распределение ресурсов, а также аспекты их перераспределения и перемещения между различными машинами, репликацию ресурсов, трудности, возникающие при одновременной работе нескольких пользователей с одним ресурсом, ошибки при доступе к ресурсам и в работе самих ресурсов.
Степень прозрачности может быть различной, поскольку скрывать от пользователя все эффекты, возникающие при работе распределенной системы, неразумно. Кроме того, прозрачность системы и ее производительность обычно находятся в обратной зависимости — например, при попытке скрыть отказы в соединении с сервером большинтво Интернет-клиентов пытается установить это соединение несколько раз, а для пользователя это выглядит как значительно замеделенная реакция системы.
-
Открытость.
Открытость системы определяется как полнота и четкость описания интерфейсов работы с ней и служб, которые она предоставляет через эти интерфейсы. Такое описание должно включать в себя все, что необходимо знать для того, чтобы пользоваться этими службами, независимо от реализации данной системы и базовой платформы.
Открытость системы важна как для обеспечения ее переносимости, так и для облегчения использования системы и возможности построения других систем на ее основе.
-
Масштабируемость.
Масштабируемость системы — это зависимость изменения ее характеристик от числа ее пользователей, числа подключенных ресурсов, а также увеличения географической распределенности системы. В число важных характеристик при этом попадают производительность, стоимость, трудозатраты на разработку, на внесение изменений, на сопровождение, на администрирование, удобство работы с системой. Для некоторых из них почти наилучшая возможная масштабируемость обеспечивается линейной зависимостью, для других хорошая масштабируемость означает, что показатель не меняется вообще при изменении масштабов системы или изменяется незначительно.
Для масштабируемой производительности обычно требуется, чтобы параметры задач, решаемых системой за одно и тоже время, можно было увеличивать достаточно быстро (лучше — линейно или еще быстрее, но это возможно не для всех задач) при возрастании количества имеющихся ресурсов, в частности, отдельных машин. В то же время, очень плохо, если внесение изменений в систему становится все более трудоемким при ее росте — желательно, чтобы трудоемкость внесения одного изменения почти не возрастала.
Иногда в масштабируемость включают административную мастабируемость системы — зависимость удобства работы с ней от числа административно независимых организаций, связанных с этой системой.
При реализации очень больших (действующих в масштабах тысяч и более пользователей) систем хорошая мастабируемость может быть достигнута с помощью следующих методов.
-
Децентрализация служб, состоящая в использовании нескольких машин для обработки поступающих запросов.
-
Децентрализация данных, состоящая в использовании нескольких хранилищ данных или нескольких копий одного хранилища.
-
Децентрализация алгоритмов, состоящая в использовании для обработки и перенаправления запросов алгоритмов, не требующих полной информации о состоянии системы, не разрушающихся при сбое одного из ресурсов системы и не предполагающих единого хода времени на всех машинах, входящих в систему.
-
Использование, где это возможно, асинхронной связи в виде передачи сообщений без приостановки работы до прихода ответа.
-
Использование комбинированных систем организации взаимодействия, основанных на иерархической организации систем (хорошо масштабирующей задачи поиска), репликации (построении копий данных и их распределении по системе для балансировки нагрузки на разные ее элементы) и его частном случае, кэшировании (организующем хранение результатов наиболее часто используемых запросов как можно ближе к клиенту), на взаимодействии точка-точка (обеспечивающем независимость от других машин в системе).
-
Безопасность.
Так как распределенные системы вовлекают в свою работу множество пользователей, машин и географически разделенных элементов, вопросы их безопасности получают гораздо большее значение, чем при работе обычных систем, сосредоточенных на одной физической машине.
Понятие безопасности включает следующие характеристики.
-
Сохранность и целостность данных.
При обеспечении групповой работы многих пользователей с одними и теми же данными нужно обеспечивать их сохранность, т.е. предотвращать исчезновение данных, введенных одним из пользователей, и в тоже время целостность, т.е. непротиворечивость, выполнение всех присущих данным ограничений.
Это непростая задача, не имеющая полного решения, удовлетворяющего все стороны во всех ситуациях — при одновременном изменении одного и того же элемента данных разными пользователями итоговый результат должен быть непротиворечив, и поэтому часто может совпадать только с вводом одного из них. Как будет обработана такая ситуация и возможно ли ее возникновение вообще, зависит от дополнительных требований к системе, от принятых протоколов работы, от того, какие риски — потерять данные одного из пользователей или значительно усложнить методы работы пользователей с системой — будут сочтены более важными.
-
Защищенность данных и коммуникаций.
При работе с коммерческими системами, с системами, содержащими большие объемы персональной и бизнес информации, с системами обслуживания пользователей государственных служб достаточно важна защищенность информации, как постоянно хранящейся в системе, так и информация одного сеанса работы. Для распределенных систем обеспечить защищенность гораздо сложнее, поскольку нельзя физически изолировать все элементы системы и разрешить доступ к ней только особо проверенным людям.
-
Отказоустойчивость и способность к восстановлению после ошибок.
Одним из достоинств распределенных систем является возможность построения более надежно работающей системы из не вполне надежных компонентов. Однако для того, чтобы это достоинство стало реальным, необходимо тщательное проектирование систем для избежания зависимости работоспособности системы от ее отдельных компонентов — иначе достоинство превращается в недостаток, поскольку в распределенной системе элементов больше и выше вероятность того, что хотя бы один элемент выйдет из строя и хотя бы один ресурс окажется недоступным.
Еще важнее для распределенных систем уметь восстанавливаться после сбоев. Уровни этого восстановления могут быть различными — так, обычно, данные одного сеанса работы считается возможным не восстанавливать, поскольку такие данные часто мало значимы или легко восстанавливаются (если это не так — стоит серьезно рассмотреть необходимость восстановления сеансов), но так называемые постоянно хранимые (persistent) данные обычно требуется восстанавливать до последнего непротиворечивого их состояния.
Ниже перечислены основные аспекты,
которые рассматривают при разработке
и анализе распределенных систем.
-
Организация связи и передачи данных между отдельными компонентами системы.
В связи с этими вопросами определяются протоколы организации связи, способы реализации обращения к процедурам и методам объектов некоторого потока из других, организация синхронной и асинхронной передачи сообщений, организация сохранности (асинхронных) сообщений в то время, когда и отправитель и получатель сообщения могут быть неактивны, организация передачи непрерывных потоков данных (аудио- и видеоданные, смешанные потоки).
-
Организация работ в рамках процессов и потоков.
В рамках данного аспекта рассматривается разделение работ в вистеме на отдельные процессы, определение ролей процессов (пример — клиентские и серверные), вопросы организации исполняемых агентов, способных мигрировать между отдельными машинами.
-
Именование и поддержка поиска отдельных ресурсов внутри системы.
К этому аспекту относятся вопросы, связанные с присвоением имен и идентификаторов различных ресурсов, с поиском ресурсов в системе по именам и атрибутам, с размещением и поиском мобильных ресурсов, изменяющих в ходе работы свое физическое положение.
Сюда же относят и организацию и поддержку сложных ссылочных структур вообще — например, вопросы удаления ставших никому не доступными ресурсов.
-
Синхронизация параллельно выполняемых потоков работ.
В рамках этого аспекта рассматриваются вопросы, связанные с организацией взаимодействия между параллельно работающими для получения общего результата потоками и процессами, алгоритмы синхронизации времени и организации работ в том случае, если в системе нельзя непротиворечиво определить глобальное время, вопросы организации транзакций.
-
Поддержка целостности данных и непротиворечивости вносимых изменений.
Этот аспект касается способов организации целостности данных и поддерживаемых при этом моделей непротиворечивости (определяющих, на основе каких требований формируются результаты выполняемых одновременно изменений и что доступно клиентам, выполнявшим эти изменения). В связи с этим определяются протоколы обеспечения непротиворечивости, создания и согласования реплик и кэшей, обеспечивающие выполнение этих моделей.
-
Организация отказоустойчивой работы.
К этому аспекту относятся вопросы обеспечения отказоустойчивости процессов, обеспечения надежной связи, протоколы подтверждения, используемые для реализации надежной двусторонней связи или надежных групповых рассылок, протоколы записей промежуточных состояний и восстановления после сбоя.
-
Организация защищенности данных и коммуникаций.
Сюда относятся вопросы обеспечения защищенности системы в целом (при этом большее значение, чем технические аспекты, имеют проблемы определения процедур проведения работ, обеспечивающих нужный уровень защищенности, и проблемы соблюдения людьми этих процедур), организации защиты данных от несанкционированног<span class="Normal__Char" style=" font-family: 'Times Ne