Прикладное программирование. Java Enterprise Edition (JEE)

1.

Прикладное
программирование
Лекция 11
Java Enterprise Edition (JEE)
Курс читается при поддержке:

2.

11. Java Enterprise Edition
Требования к enterprise-приложениям
Надѐжность. ПО enterprise-уровня является важным для работы
организации, от него ожидают надѐжности и отсутствия ошибок.
Производительность и масштабируемость. Приложения должны
отвечать требованиям к производительности и проявлять достаточную
масштабируемость – возможность справляться с увеличенной нагрузкой
при наличии необходимого аппаратного обеспечения. В большинстве
случаев это требует развѐртывания нескольких серверов и их
объединения в кластер.
Поддерживаемость и расширяемость. Поддержка является самой
дорогой фазой жизненного цикла ПО, а так как с высокой вероятностью
enterprise-приложения на долгие годы будут ключевым компонентом
программной среды предприятия, то они должны адаптироваться к
новым требованиям бизнеса.
Разработка в заданные сроки.
Повторное использование компонентов. Enterprise-приложения
должны укладываться в долгосрочную стратегию развития организации,
что требует повторного использования компонентов, минимизирующего
дублирование кода (как внутри, так и между проектами) и требуемые
инвестиции.
Поддержка различных типов клиентов.
2
Переносимость.
Д.А.Стрикелев. Прикладное программирование

3.

11. Java Enterprise Edition
Эволюция enterprise-приложений
За время своего существования enterprise-приложения
претерпели существенные эволюционные
изменения.
Первое поколение enterprise-приложений состояло из
централизованных приложений на мэйнфреймах.
В конце 1980-ых, начале 1990-ых большинство новых
enterprise-приложений строилось по двухуровневой
(клиент-серверной) архитектуре.
В дальнейшем enterprise-приложения развились до
трѐхуровневой архитектуры, а затем до архитектуры
на основе web-технологий.
3
Д.А.Стрикелев. Прикладное программирование

4.

11. Java Enterprise Edition
Двухуровневая архитектура «клиент-сервер»
В случае двухуровневой архитектуры система
структурирована как множество прикладных процессов на
уровне операционной системы, которые выполняются на
машине-клиенте. Каждое такое приложение реализует:
Один или несколько бизнес-процессов (инкапсулирующих
взаимодействия пользователя с информацией предприятия);
Графический интерфейс пользователя (содержащий логику
представления взаимодействий между пользователем и бизнеспроцессами).
Приложение работающее на машине-клиенте взаимодействует
через сеть с сервером баз данных, хранящим корпоративные
данные. Сервер баз данных отвечает только за хранение этих
данных, а клиентские приложения обычно обращаются к
данным посредством SQL (Structured Query Language) запросов.
До появления технологий web, двухуровневая архитектура хорошо
отвечала требованиям большинства приложений. Еѐ основное
преимущество заключается в лѐгкости разработки, что отчасти
объясняется тем, что логика представления и бизнес-логика
расположены в одном и том же процессе, и разработчику не
приходится иметь дело со сложностью распределѐнных
приложений.
Д.А.Стрикелев. Прикладное программирование
4

5.

11. Java Enterprise Edition
Двухуровневая архитектура «клиент-сервер»
5
Д.А.Стрикелев. Прикладное программирование

6.

11. Java Enterprise Edition
Недостатки архитектуры «клиент-сервер» – Часть 1
Недостатки архитектуры, к сожалению, перевешивают еѐ
достоинства. Основной проблемой является то, что
программисты не могут чѐтко разделить бизнес-логику от логики
представления. Это порождает ряд проблем:
Лѐгкость нарушения целостности базы данных. Так как каждая
программа-клиент включает бизнес-логику, ошибка или сбой в работе
клиента легко могут нарушить целостность корпоративной базы
данных.
Сложность администрирования на крупном предприятии. В
рассматриваемой архитектуре приложение развѐртывается на всех
клиентских машинах, и при изменении бизнес-процессов все копии
приложения должны быть обновлены.
Сложность поддержки кода. Двухуровневая архитектура не
поддерживает модульного программирования, делая поддержку кода
сложной. Еѐ сложность увеличивается экспоненциально для крупных
организаций, использующих большее число программистов для
написания и поддержки приложений.
6
Д.А.Стрикелев. Прикладное программирование

7.

11. Java Enterprise Edition
Недостатки архитектуры «клиент-сервер» – Часть 2
Делает приложение уязвимым для нарушений
системы безопасности. Умелый программист может
взломать приложение, установленное на машине-клиенте,
и изменить реализуемые им бизнес-процессы.
Ограниченность масштабируемости. Масштабирование
приложения на большое число пользователей затруднено.
Каждое работающее приложение обычно требует подключения
к корпоративной базе данных. Так как число открытых
соединений в большинстве случаев ограничено используемым
программным продуктом СУБД, может оказаться, что не все
пользователи смогут работать с приложением одновременно.
Требует однородности клиентской среды. До появления
языка программирования Java, двухуровневые приложения
требовали однотипности машин-клиентов.
Ограничивает приложение одним определѐнным типом
представления. Так как приложение-клиент реализует не
только бизнес-процессы, но и средства представления, может
оказаться невозможным повторно использовать имеющуюся
реализацию бизнес-процессов с другим способом
представления, таким как браузер или смартфон.
7
Д.А.Стрикелев. Прикладное программирование

8.

11. Java Enterprise Edition
Архитектура «клиент-сервер» - Итоги
Стремительное увеличение популярности webтехнологий изменило взгляд на архитектуру
программных систем. Если до появления технологий
web корпорации могли смиряться с ограничениями
двухуровневой архитектуры, то сама природа webтехнологий несовместима с названными
ограничениями. В основном это обусловлено
ограниченной интеллектуальностью web-клиентов и
их большим числом.
Кроме того, ограничения двухуровневой архитектуры
делают невозможной интеграцию бизнес-приложений
с приложениями партнѐров, клиентов и поставщиков.
8
Д.А.Стрикелев. Прикладное программирование

9.

11. Java Enterprise Edition
Трѐхуровневая архитектура
Традиционная трѐхуровневая архитектура
преодолевает ограничения двухуровневой: она
отделяет логику представления от бизнес-логики; бизнеслогика помещается на сервер, в то время как на машинеклиенте остаѐтся только логика представления.
Трѐхуровневая архитектура приносит с собой ряд
улучшений:
Улучшается масштабируемость системы за счѐт
повторного использования «дорогих» ресурсов, таких как
подключения к базам данных, на серверах
промежуточного слоя.
Улучшается производительность за счѐт увеличения
вычислительных мощностей промежуточного слоя.
Улучшается уровень защищѐнности и лѐгкость
администрирования.
Д.А.Стрикелев. Прикладное программирование
9

10.

11. Java Enterprise Edition
Трѐхуровневая архитектура
10
Д.А.Стрикелев. Прикладное программирование

11.

11. Java Enterprise Edition
Недостатки трѐхуровневой архитектуры – Часть 1
Не смотря на то, что она устраняет часть недостатков двухуровневой
архитектуры, трѐхуровневой архитектуре самой присущ ряд
недостатков:
Сложность — Разработка трѐхуровневого приложения является более
сложной, программисты должны иметь дело с распределением задач,
многопоточностью, безопасностью и т.д. В попытке уменьшить
сложность распределѐнных приложений рядом производителей были
предложены специализированные программные каркасы для
разработки приложений, такие, например, как мониторы транзакций.
Недостаточная переносимость приложений — так как каждый
производитель прикладных программных каркасов для трѐхуровневых
платформ использует отличающийся набор программных интерфейсов
(API), для независимых разработчиков программного обеспечения
становится невозможным создавать приложения, которые могут
развѐртываться на серверах приложений различных производителей.
11
Д.А.Стрикелев. Прикладное программирование

12.

11. Java Enterprise Edition
Недостатки трѐхуровневой архитектуры – Часть 2
Несовместимость компонентов различных
разработчиков — интеграция компонентов различных
разработчиков является затруднѐнной, так как каждый из них
использует отличный набор протоколов и не существует
стандартных средств взаимодействия между ними.
Несовместимость с технологиями web — традиционная
трѐхуровневая архитектура напрямую не взаимодействует в
web, так как для связи между клиентов и приложением
промежуточного слоя используется собственный протокол
взаимодействия, не совместимый с web. В программных
каркасов некоторых разработчиков данный недостаток
устранѐн добавлением поддержки web-клиентов.
12
Д.А.Стрикелев. Прикладное программирование

13.

11. Java Enterprise Edition
Ранняя архитектура web-приложений
Так как ни двухуровневая, ни традиционная
трѐхуровневая архитектуры не поддерживают
разработки web-приложений, ранние разработчики
web-приложений были вынуждены использовать другой
подход. Они применяли различные модули расширений
для web-серверов, которые обращались к размещѐнным
на серверах программам для динамического
конструирования HTML (HyperText Markup Language)
документов на основе данных, хранящихся в
корпоративных СУБД. Кроме того, эти же модули
расширений сохраняли передаваемые в HTML-формах
данные в корпоративных СУБД.
Примером подобного расширения могут являться CGIскрипты (Common Gateway Interface – интерфейс для
разработки HTML страниц и web-приложений).
13
Д.А.Стрикелев. Прикладное программирование

14.

11. Java Enterprise Edition
Недостатки ранней архитектуры web-приложений
Не смотря на то, что CGI-скрипты и схожие механизмы позволяли
разрабатывать простые web-приложения, этот подход не
масштабировался на более сложные enterprise-приложения:
CGI-скрипты не предоставляют хорошо структурированной
инкапсуляции бизнес-процессов или бизнес-сущностей.
CGI-скрипты сложны в разработке, поддержке и управлении. Средства
разработки высого уровня не предлагают хорошей поддержки для
разработки CGI-скриптов.
CGI-скрипты перемежают реализацию бизнес-логики с реализацией
логики представления. Когда требуется изменить одну часть
реализации, например бизнес-процессы, вторая часть также
вынуждено изменится.
Реализация бизнес-правил предприятия разбросана по многим CGIскриптам, размещѐнным на множестве web-серверов предприятия, что
затрудняет поддержание целостности набора бизнес-правил.
Производительность приложений на основе CGI-скриптов существенно
ниже, что обусловлено самой природой их интерпретации «на лету».
14
Д.А.Стрикелев. Прикладное программирование

15.

11. Java Enterprise Edition
Архитектура JEE
JEE является стандартной архитектурой,
предназначенной для разработки и размещения
web-ориентированных приложений масштаба
предприятия с использованием языка Java. JEE может
быть использована не только для создания Интранетприложений, эффективно заменяя двух- и трѐхуровневую
архитектуры, но и для разработки web-приложений, с
успехом заменяя подход на основе CGI.
JEE предоставляет гибкую модель разделения
программного обеспечения на уровни, позволяющую
предприятиям конструировать свои приложения в
наиболее удобной форме. Эта модель поддерживает все
предыдущие поколения архитектур программного
обеспечения и поддерживает новую архитектуру на
основе web-сервисов.
15
Д.А.Стрикелев. Прикладное программирование

16.

11. Java Enterprise Edition
Уровни архитектуры JEE
Каждая из архитектур программных комплексов на
основе J2EE включает три основных уровня, хотя в
некоторых вводится дополнительное деление
промежуточного уровня на ряд подуровней. Опыт
разработки показал ценность чѐткого разделения систем
предприятий на ряд уровней, что позволяет обеспечить
чѐткое разделение ответственности.
В хорошо спроектированной многоуровневой системе
каждый уровень должен зависеть только от нижнего
уровня.
Детали построения конкретного уровня должны быть
скрыты от других уровней.
Эти два принципа обеспечивают лѐгкую модифицируемость
приложений без необходимости выполнения каскадных
изменений на других уровнях.
16
Д.А.Стрикелев. Прикладное программирование

17.

11. Java Enterprise Edition
Уровень информационных систем предприятия (ИСП)
Называемый также уровнем интеграций, уровень состоит из
ресурсов предприятия, к которым JEE-приложение должно
иметь доступ. Ресурсы включают системы управления
базами данных (СУБД) и унаследованные приложения
мэйнфреймов, и обычно являются транзакционными.
Влияние архитектора системы на построение и развѐртывание
уровня в большинстве случаев определяется природой проекта
– разработкой чего-либо «с нуля» или интеграцией с
существующими системами. В последнем случае особенности
реализации уровня могут влиять на построение промежуточного
слоя.
JEE-архитектура предоставляет широкие возможности для
взаимодействия с ресурсами, такие как Java Database
Connectivity (JDBC) для доступа к реляционным БД, Java
Naming and Directory Interface (JNDI) для доступа к серверам
каталога и Java Connector Architecture (JCA) для доступа к
другим системам. Уровень находится вне влияния JEE-сервера,
но сервер отвечает за пулинг подключений к ресурсам,
управление транзакциями и защиту систем от нарушения
безопасности со стороны JEE-приложений.
17
Д.А.Стрикелев. Прикладное программирование

18.

11. Java Enterprise Edition
Промежуточный уровень
Уровень содержит объекты, реализующие
бизнес-логику приложения, и является посредником
при доступе к ресурсам уровня информационных систем
предприятия. Компоненты промежуточного слоя в
наибольшей степени пользуются предоставляемой
функциональностью JEE-контейнера, такой как поддержка
транзакций и пулинг соединений к ресурсам, и не зависят
от уровня пользовательского интерфейса.
Компоненты промежуточного слоя могут быть
распределѐнными, что предъявляет к ним ряд
дополнительных требований. JEE-контейнер избавляет
разработчиков компонентов от необходимости
самостоятельной реализации ряда востребованных
возможностей, предлагая им уже готовый набор сервисов.
18
Д.А.Стрикелев. Прикладное программирование

19.

11. Java Enterprise Edition
Требования к распределѐнным компонентам – Часть 1
Удалѐнный вызов методов. Необходима логика,
соединяющая уровни друг с другом через сетевые соединения –
т.е. уровень представления с промежуточным уровнем, а
промежуточный уровень – с уровнем информационных систем.
Это включает маршрутизацию запросов к методам, обработку
параметров, перенаправление SQL-запросов и др.
Балансирование нагрузки. Клиенты уровня представления
должны направляться к серверам промежуточного уровня и баз
данных, обладающих наименьшей загрузкой. В случае
перегрузки сервера необходимо переключение части запросов
на другой сервер.
Прозрачная отказоустойчивость. Если сервер или сеть
выходят из строя, клиенты должны быть перенаправлены на
другие серверы без остановки обслуживания.
Интеграция с уровнем информационных систем.
Необходимо наличие кода для сохранения бизнес-данных в
СУБД и интеграции с существующими системами.
19
Д.А.Стрикелев. Прикладное программирование

20.

11. Java Enterprise Edition
Требования к распределѐнным компонентам – Часть 2
Транзакционность. Должна присутствовать защита от
одновременного доступа клиентов и неожиданного сбоя
компонентов.
Кластеризация. Обеспечение сохранения состояния сервера с
репликацией на другие серверы, чтобы в случае сбоя сервера
обслуживание могло быть продолжено на другом сервере.
Динамическое размещение. Возможность осуществлять
обновление программных компонентов без остановки
программного комплекса.
Аккуратное завершение. В случае необходимости остановки
сервера возможность сделать это аккуратно, без прерывания
обслуживания тех клиентов, которые уже подключены и его
используют.
Протоколирование и аудит. Ведение протокола всех событий,
предоставляющего дополнительные сведения для анализа
причин произошедшего сбоя.
Управление системой. Уведомление администратора системы
о возникших неполадках в случае катастрофического сбоя
системы.
20
Д.А.Стрикелев. Прикладное программирование

21.

11. Java Enterprise Edition
Требования к распределѐнным компонентам – Часть 3
Многопоточность. При подключении к серверу множества
клиентов необходима возможность параллельной обработки
запросов клиентов, т.е. сервер должен быть многозадачным.
Ориентированность на передачу сообщений. Определѐнные
типы запросов должны быть ориентированными на передачу
сообщений, в которой клиенты и серверы связаны весьма
слабо.
Управление жизненным циклом компонентов. Компоненты,
существующие внутри сервера, должны быть созданы и
корректно уничтожены при изменении потока запросов
(увеличении или уменьшении).
Пулинг ресурсов. Если клиент в настоящий момент не
пользуется ресурсом, то этот ценный ресурс может быть
возвращѐн в пул и повторно использован для запросов других
клиентов.
Безопасность. Серверы и СУБД должны быть защищены от
противоправных действий. Только определѐнные пользователи
должны иметь возможность выполнения операций, для которых
у них имеется надлежащий набор разрешений.
Кэширование. Повторяемые операции должны быть
оптимизированы и закэшированны.
21
Д.А.Стрикелев. Прикладное программирование

22.

11. Java Enterprise Edition
Программный каркас Enterprise Java Beans
Enterprise JavaBeans (EJB) это программный каркас для
серверных компонентов, который упрощает построение
приложений уровня предприятия на основе
распределѐнных компонентов. С использованием EJB возможно
создание масштабируемых, надѐжных и защищѐнных
приложений без необходимости разработки собственных
распределѐнных программных платформ. EJB предназначен
для быстрой разработки серверных приложений – разработчики
могут быстро и легко конструировать серверные компоненты в
Java используя существующую распределѐнную
инфраструктуру – и спроектирован для поддержки
переносимости и повторного использования компонентов на
платформах различных производителей
Другими словами, EJB это компонент, предназначенный для
использования в окружении, предоставляемом программным
каркасом EJB.
22
Д.А.Стрикелев. Прикладное программирование

23.

11. Java Enterprise Edition
Типовые задачи EJB-компонентов
Реализация бизнес-логики. Примеры включают вычисление
суммы налогов для товаров в корзинке покупателя в Интернетмагазине, проверку прав менеджера на подтверждение
сделанного заказа, отправку уведомления об успешной покупке
с использованием JavaMail API.
Доступ к данным. Примеры включают размещение заказа на
покупку книг, перевод денег между банковскими счетами, вызов
хранимой процедуры для получения списка клиентов для
выставления счѐта и т.п. EJB могут получать доступ к данным с
помощью разнообразных способов, один из которых это
интерфейс Java Database Connectivity (JDBC).
Интеграция с другими системами. EJB могут использоваться
для интеграции с другими системами, например, посредством
Java Connector Architecture (JCA).
23
Д.А.Стрикелев. Прикладное программирование

24.

11. Java Enterprise Edition
Уровень пользовательского интерфейса
Данный уровень предоставляет пользователям
интерфейс для взаимодействия с объектами,
реализующими бизнес-логику и принадлежащими
промежуточному уровню. В web-приложениях он
состоит из:
сервлетов;
вспомогательных классов, используемых
сервлетами;
view-компонентов, например JSP-страниц.
Для ясности, при обсуждении web-приложений уровень
пользовательского интерфейса будем называть
также web-уровнем.
24
Д.А.Стрикелев. Прикладное программирование

25.

11. Java Enterprise Edition
Нераспределѐнные JEE-архитектуры
Следующие архитектуры программных комплексов
применимы для web-приложений:
Web-приложение с интерфейсами бизнескомпонентов;
Web-приложение, использующее локальные EJB.
Оба способа построения приложений основаны на
запуске компонентов в единой копии JVM, что делает
их простыми и эффективными, но ограничивает
гибкость развѐртывания.
25
Д.А.Стрикелев. Прикладное программирование

26.

11. Java Enterprise Edition
Web-приложение с интерфейсами бизнес-компонентов
В большинстве случаев JEE применяется для построения webприложений, что позволяет JEE-контейнеру представлять полную
инфраструктуру, необходимую большинству приложений. Webприложения на основе JEE имеют аналогичный доступ к большинству
программных интерфейсов, как и EJB-компоненты. Они могут
использовать возможности по управлению транзакциями и по пулингу
подключений к ресурсам, предлагаемые JEE-сервером, а также
применять такие сервисы предприятия как JDBC, JavaMail, JCA и проч.
The web tier and middle tier of a web application run in the same JVM.
Следует отметить, что ключевым вопросом является логической
разделѐнности уровней. Основной проблемой в проекте webприложений является размывание ответственности между
компонентами пользовательского интерфейса и компонентами бизнеслогики.
Слой бизнес-интерфейсов состоит из Java-интерфейсов, реализуемых
обычными Java-классами. Эта архитектура является достаточно
простой, но масштабируемой, и удовлетворяет запросам большинства
приложений.
26
Д.А.Стрикелев. Прикладное программирование

27.

11. Java Enterprise Edition
Web-приложение с интерфейсом бизнес-компонентов
27
Д.А.Стрикелев. Прикладное программирование

28.

11. Java Enterprise Edition
Web-приложение с интерфейсом бизнес-компонентов – Преимущества
Простота. Данная архитектура является самой простой для webприложений. Однако, если необходимость управления транзакциями
или многопоточная обработка запросов требуют создания
неоправданно сложного кода, использование EJB будет разумнее.
Скорость работы. Подобная архитектура требует минимальных
дополнительных затрат на обработку со стороны JEE-сервера.
Ясность. Объектно-ориентированная модель системы не подвержена
дополнительному усложнению из-за особенностей JEE-компонентов,
таких как ограничения на вызов EJB-компонентов.
Лѐгкость тестирования. При грамотном проекте системы, тесты могут
запускаться для проверки работоспособности бизнес-интерфейсов без
вовлечения в процесс уровня пользовательского интерфейса.
Возможность использования встроенной в JEE-сервер поддержки
транзакций.
Масштабируемость. Если компоненты web-интерфейсов не имеют
состояния, от контейнера не требуется поддержки кластеризации. В то
же время, компоненты могут быть и распределѐнными, если
использовать возможности по поддержке репликации состояния
сессий.
28
Д.А.Стрикелев. Прикладное программирование

29.

11. Java Enterprise Edition
Web-приложение с интерфейсом бизнес-компонентов – Недостатки
Поддерживает только web-интерфейс. Не может
поддерживать самостоятельных клиентов с графическим
интерфейсом (т.к. промежуточный слой расположен в той
же JVM, что и уровень интерфейса).
Всѐ приложение работает в единой JVM. В то время как
это улучшает производительность, произвольное
размещение компонентов по различным физическим
серверам невозможно.
Не может использовать поддержку транзакций EJBконтейнера, что требует создавать транзакции и
управлять ими непосредственно в коде приложения.
Сервер не предоставляет поддержки параллельного
программирования, что вынуждает решать связанные с
многопоточностью вопросы самостоятельно или с
помощью специализированных библиотек.
29
Д.А.Стрикелев. Прикладное программирование

30.

11. Java Enterprise Edition
Web-приложение, использующее локальные EJB
Подобная архитектура обеспечивает доступ объектам webуровня к EJB-компонентам через локальные интерфейсы, при
условии, что приложение развѐрнуто в интегрированном JEEсервере, работающем в единой JVM. Это позволяет
воспользоваться всеми службами, предлагаемыми EJBконтейнером, без дополнительного усложнения приложения или
распределения его компонентов.
В этом случае web-уровень и бизнес-интерфейсы аналогичны
предыдущему случаю. Различия заключаются в том, что
промежуточный слой разделѐн на два подуровня (бизнесинтерфейсы, работающие в web-контейнере, и EJB-компоненты),
но оба они функционируют в единой JVM.
30
Д.А.Стрикелев. Прикладное программирование

31.

11. Java Enterprise Edition
Web-приложение, использующее локальные EJB
31
Д.А.Стрикелев. Прикладное программирование

32.

11. Java Enterprise Edition
Web-приложение, использующее локальные EJB – Преимущства
Более простая архитектура, чем распределѐнное
EJB-приложение.
Применение EJB не изменяет общую структуру
приложения. В качестве EJB-компонентов
оформляются только те объекты, которым требуются
услуги EJB-контейнера.
Использование EJB выражается в сравнительно
небольшой потере производительности, т.к.
удалѐнный вызов методов или сериализация
объектов не применяются.
Предоставляет преимущества управления
транзакциями и потоками, реализованными в EJBконтейнере.
32
Д.А.Стрикелев. Прикладное программирование

33.

11. Java Enterprise Edition
Web-приложение, использующее локальные EJB – Недостатки
Архитектура более сложная, чем у базового webприложения. Например, развѐртывание EJBкомпонентов и загрузка классов являются более
сложными.
По-прежнему не может поддерживать клиентов
других типов, кроме использующих web-интерфейс
(за исключением добавления слоя web-сервисов).
Всѐ приложение функционирует в единой JVM, что
значит, что все его компоненты должны
располагаться на одном и том же физическом
сервере.
Затруднѐнная отладка EJB-компонентов с
локальными интерфейсами. Тесты должны
запускаться изнутри JEE-сервера.
Д.А.Стрикелев. Прикладное программирование
33

34.

11. Java Enterprise Edition
Распределѐнные JEE-архитектуры
Следующих два вида архитектур на основе JEE
поддерживают как web-приложения, так и удалѐнных
клиентов:
Распределѐнные приложения с удалѐнными EJB;
Web-приложения с интерфейсом web-сервисов.
34
Д.А.Стрикелев. Прикладное программирование

35.

11. Java Enterprise Edition
Распределѐнные приложения с удалѐнными EJB
Данная архитектура широко известна как
«классическая» JEE-архитектура. Она
предоставляет возможность физического и логического
разделения EJB промежуточного слоя и использующих их
компонентов (например, web-компонентов) по различным
JVM. Данная архитектура является сложной, с
существенными вычислительными затратами на
функционирование, но может поддерживать JEE-клиентов
любого типа.
Для взаимодействия между уровнем пользовательского
интерфейса и бизнес-объектами, представленными как
EJB, применяется протокол RMI, что делает удалѐнный
вызов методов главной детерминантой при определении
производительности системы и ключевым вопросом
проектирования. Основной задачей является
минимизация количества удалѐнных вызовов.
35
Д.А.Стрикелев. Прикладное программирование

36.

11. Java Enterprise Edition
Распределѐнные приложения с удалѐнными EJB
36
Д.А.Стрикелев. Прикладное программирование

37.

11. Java Enterprise Edition
Распределѐнные приложения с удалѐнными EJB – Преимущества
Архитектура поддерживает все типы клиентов
предоставляя совместно используемый
промежуточный уровень.
Позволяет распределять компоненты приложения по
различным физическим серверам. Особенно
эффективно это может применяться если уровень
EJB-компонентов не хранит состояний, позволяя
использовать stateless EJB.
37
Д.А.Стрикелев. Прикладное программирование

38.

11. Java Enterprise Edition
Распределѐнные приложения с удалѐнными EJB – Недостатки
Данная архитектура является наиболее сложной из
всех рассмотренных. Если эта сложность не
обоснована требованиями к программному продукту,
то высока вероятность бессмысленного перерасхода
ресурсов и благоприятных условий для множества
ошибок.
Отрицательно влияет на производительность.
Удалѐнные вызовы методов могут быть в сотни раз
медленнее, чем локальные вызовы по ссылке.
Общее влияние на производительность системы
существенно зависит от необходимого числа
удалѐнных вызовов.
Распределѐнные приложения сложны в
тестировании и отладке.
В распределѐнных системах обработка исключений
является более сложной. Приходится ожидать как
сбоев в приложении, так и сбоев в транспортных
механизмах при передаче данных по сети.
38
Д.А.Стрикелев. Прикладное программирование

39.

11. Java Enterprise Edition
Web-приложение с интерфейсом web-сервисов
Возникновение стандартов на web-сервисы, такие как
протокол SOAP, означает, что JEE-приложения более не
обязаны использовать протокол RMI и EJB для поддержки
удалѐнных клиентов. Подобная архитектура позволяет
взаимодействовать и с не-JEE клиентами, например
приложениями Microsoft.
Данная архитектура добавляет любому JEE-приложению
объектный уровень, предоставляющий web-сервисы, и
транспортный уровень, реализующий необходимые протоколы.
Компоненты web-сервисов могут функционировать либо в том же
web-контейнере, что и традиционный web-интерфейс, или быть
единственным интерфейсом, поддерживаемым приложением..
Данная архитектура отличается от распределѐнной EJBархитектуры не только в используемом протоколе (SOAP вместо
RMI), но и в том, что удалѐнный интерфейс обычно добавляется к
существующему приложению, а не встраивается в структуру
приложения изначально. Это позволяет добавлять поддержку webсервисов к любой из трѐх рассмотренных ранее архитектур
(особенно 1-ой или 2-ой). Использование web-сервисов устраняет
одну из основных причин для использования EJB с удалѐнными
интерфейсами.
39
Д.А.Стрикелев. Прикладное программирование

40.

11. Java Enterprise Edition
Web-приложение с интерфейсом web-сервисов
40
Д.А.Стрикелев. Прикладное программирование

41.

11. Java Enterprise Edition
Web-приложение с интерфейсом web-сервисов – Преимущества
Протокол SOAP является более открытым чем
RMI/IIOP. Эта архитектура может поддерживать
клиентов других платформ, не только JEE.
Опубликование интерфейса web-сервисов может быть более
предпочтительным, чем опубликование RMI-интерфейса.
Транспортные протоколы web-сервисов работают на основе
протокола HTTP и в большей степени поддерживаются
брандмауэрами, а также легче воспринимаются человеком.
Предоставление удалѐнного доступа является
дополнительной чертой, не задающей цельную архитектуру
системы. Например, решение использовать или не
использовать EJB может приниматься исходя из лучшего
варианта построения приложения, а не в зависимости от
того, как к нему будет осуществляться доступ (удалѐнно).
41
Д.А.Стрикелев. Прикладное программирование

42.

11. Java Enterprise Edition
Web-приложение с интерфейсом web-сервисов – Недостатки
Производительность. Затраты на передачу объектов
с помощью протокола на основе XML (такого как
SOAP) будут более высокими, чем при
использовании протокола RMI.
В случае, если все клиенты приложения используют
технологию JEE, данная архитектура уступает
классической архитектуре JEE-приложения.
Упаковка и распаковка сложных объектов может
потребовать написания дополнительного кода. Так
как объекты передаются по сети как XML-документы,
может возникнуть необходимость преобразования
Java-объектов в/из XML.
42
Д.А.Стрикелев. Прикладное программирование

43.

На сегодня всѐ, до свидания и до
следующей встречи!