SCEA krocodls notes

ОБЩИЕ ПОНЯТИЯ.......................................................................................................................3
Архитектура .................................................................................................................................................................................3

Архитектор....................................................................................................................................................................................4

Другая терминология..................................................................................................................................................................5

Принципы ООП...........................................................................................................................................................................5

Требования уровня сервисов.....................................................................................................................................................6

Двухзвенная архитектура...........................................................................................................................................................8

Трехзвенная архитектура...........................................................................................................................................................9

J2EE ОБЗОР...............................................................................................................................11
общие идеи...................................................................................................................................................................................11

Стандартные роли.....................................................................................................................................................................12

API.................................................................................................................................................................................................12

Протоколы...................................................................................................................................................................................13

Контейнеры.................................................................................................................................................................................13

EJB................................................................................................................................................................................................14

Транзакции..................................................................................................................................................................................14

ДОКУМЕНТИРОВАНИЕ АРХИТЕКТУРЫ.................................................................................14
Общие идеи..................................................................................................................................................................................14

Жизненный цикл приложения................................................................................................................................................15

Структура UML..........................................................................................................................................................................15

ШАБЛОНЫ ПРОЕКТИРОВАНИЯ.............................................................................................18
общее.............................................................................................................................................................................................18

MVC..............................................................................................................................................................................................18

Best Practices................................................................................................................................................................................19

J2EE..............................................................................................................................................................................................21

Gof.................................................................................................................................................................................................27
Создание объектов..................................................................................................................................................................27
Структурные шаблоны...........................................................................................................................................................30
Поведенческие шаблоны........................................................................................................................................................33

БЕЗОПАСНОСТЬ.......................................................................................................................37
общее.............................................................................................................................................................................................37

Обзор потенциальных угроз....................................................................................................................................................38

Составные аспекты безопасности...........................................................................................................................................40

Проектирование и разработка................................................................................................................................................41

Архитектура безопасности J2SE ............................................................................................................................................47

Java Cryptography Architecture (JCA)....................................................................................................................................52

Java Cryptography Extensions (JCE) ......................................................................................................................................54

Производные API на основе JCA/JCE...................................................................................................................................57

Java Authentication and Authorization Service (JAAS).........................................................................................................60

Архитектура безопасности J2EE ............................................................................................................................................64

ШАБЛОНЫ БЕЗОПАСНОСТИ..................................................................................................69
общие шаблоны..........................................................................................................................................................................69

Веб слой........................................................................................................................................................................................69

Бизнес слой..................................................................................................................................................................................79

Веб сервисы.................................................................................................................................................................................85

Identity management...................................................................................................................................................................91

Secure Service Provisioning – подготовка сервисов к использованию пользователями...............................................94

ЛОКАЛИЗАЦИЯ..........................................................................................................................97
общее.............................................................................................................................................................................................97

ПРОТОКОЛЫ..............................................................................................................................97

УНАСЛЕДОВАННЫЕ СИСТЕМЫ И ИНТЕГРАЦИЯ...............................................................97

общее.............................................................................................................................................................................................97

Обзор JCA .................................................................................................................................................................................100

Реализация JCA адаптера – 1.0.............................................................................................................................................102

Реализация JCA адаптера – 1.5.............................................................................................................................................103

Поддержка CCI.........................................................................................................................................................................104

RMI.............................................................................................................................................105
Основы ......................................................................................................................................................................................105

RMI и CORBA...........................................................................................................................................................................109

недостатки и расширения......................................................................................................................................................110
EJB.............................................................................................................................................111
Различные замечания.............................................................................................................................................................111

MESSAGING..............................................................................................................................112
Общие замечания.....................................................................................................................................................................112

Основные компоненты...........................................................................................................................................................113

Обзор API - пакет javax.jms ...................................................................................................................................................114

Шаблоны интеграции.............................................................................................................................................................116
Базовые шаблоны..................................................................................................................................................................116
Каналы....................................................................................................................................................................................116
Сообщения.............................................................................................................................................................................120
Маршрутизация сообщений.................................................................................................................................................125
Трансформация сообщений..................................................................................................................................................137
Конечные точки обмена сообщениями...............................................................................................................................141
Управление системой...........................................................................................................................................................149

Общие понятия
Архитектура
• Термин «enterprise» требует от приложения: расширяемость, доступность, надежность,
безопасность, поддержка транзакций и распределенность.
• Типы архитектур
• Системная архитектура – архитектура как продукт, в результате имеем набор
компонент, их интерфейсов, описаний их взаимодействий и набор общих
ограничений. Базис для проектирования и разработки
• Эталонная архитектура - набор структурных принципов, которые позволяют системе
раскладываться на более простые подсистемы.
• Каждая из подсистем имеет свой собственный независимый от других контекст,
который отличен от контекста системы в целом
• Базис для создания системной архитектуры конкретной системы
• Состоит из - унифицированной терминологии, принципов распределения
обязанностей, перечня стандартных компонентов, примеров стандартных
архитектур, методологии разработки.
• Гибкость эталонной архитектуры обеспечивается:
• Перечень элементов, обеспечивающих возможность
переконфигурирования системы и ее адаптацию к изменяющемуся
окружению
• Характеристики объектов, посредством которых обеспечивается их
участие в ^процессах
• Правила проектирования, которые обеспечивают сохранение гибкости
системы
• Результат разработки архитектуры в виде документов по
• Системной архитектуре – описание существующего железа, по, топологии сети и
других базовых компонент
• Архитектуре приложения – общая структура, перечень компонент, варианты их
использования и унаследованные компоненты
• Руководство по дизайну компонент и архитектурные решения, которые должны
сохраняться в процессе проектирования, их варианты
 • Прототип использования новых технологий в проекте, для проверки и тренировки
проектантов и разработчиков
• Этапы разработки приложения
• Анализ требований и проблемы
• что система должна делать, чтобы исполнители удовлетворили заказчиков
• создание модели предметной области, описание классов, объектов и
взаимодействий без технических подробностей
• результат – исходная точка для создания архитектуры
• ООП архитектурный анализ
• ООП анализ предметной области
• Артефакты – модель прецедентов, последовательностей, классов и
сотрудничества
• Разработка архитектуры
• выбор или создание каркаса, в котором выявленные компоненты приложения
смогут удовлетворить требования заказчика
• Выявление новых требований к железу и базовому ПО
• Выяснение того, как
• удовлетворить требования безопасности, производительности в рамках
заданной стоимости
• повторно использовать уже освоенные технологии, а также унаследованные
программные компоненты
• Результат – диаграмма пакетов, как именно классы в разных пакетах будут
взаимодействовать, диаграмма развертывания, перечень базовых программных
компонент
• ООП проектирование и разработка
• Определение внутренней структуры для всех выявленных ранее артефактов
• Использование шаблонное проектирования
• Обсуждение вопросов повторного использования классов
• Уточнение сделанных ранее архитектурных решений

Архитектор
• Визуализирует поведение системы, создает BluePrint, определяет перечень элементов
системы и способ их взаимодействия друг с другом
• Архитектор имеет дело с техническими рисками системы. Обычно эти риски связаны с
требованиями уровня сервисов (качества сервисов, QoS), но могут быть и с бизнес
требованиями
• Ограничения в работе архитектора
• Архитектурные проблемы – удовлетворение функциональных и нефункциональных
требований, перспективы развития системы
• Ресурсные - опыт, техническая сложность, профессионализм разработчиков,
• Стоимостные – время и масштаб проекта
• Должен иметь хороший уровень устной и письменной коммуникации с членами
проекта, одно из ключевых требований
• Основное взаимодействие с заинтересованными сторонами производится на уровне
interception / elaboration фаз проекта, когда определяются критерии достижения качества
обслуживания для каждого из требований уровня сервисов
• Разница с designer:
• тот отвечает на вопрос «что происходит, когда пользователь нажмет кнопку»,
а архитектор «что происходит, когда 1000 пользователей нажмет кнопку
одновременно»
 • архитектура имеет дело с общими принципами, а проектирование с
конкретными вариантами использования и отображением модели предметной
области с объектную модель системы

Другая терминология
• Surface area – область ответственности компонента, в которой он влияет на другие
компоненты
• Boundaries – границы, через которые идет взаимодействие между разными
компонентами
• Brittleness – степень, в которой малые изменения в компоненте, влекут за собой
большие изменения в системе
• Friction – насколько часты взаимодействия между двумя компонентами
• Layer – подсистема в системе, взаимодействие в системе между слоями может быть
двунаправленное и однонаправленное, внутри одного слоя не должно быть циклических
зависимостей между пакетами

Принципы ООП
• Основные
• Encapsulation - сокрытие внутренней структуры данных и реализации методов
объекта от остальной программы. Гарантирует модульности кода
• Inheritance – передача знаний вниз, требуется меньше программирования для
добавления новой функциональности в существующую систему.
• Polymorphism – способность оперировать объектами, точный тип которых не
известей в момент выполнения
• Зависимости классов
• Open closed principle (OCP) – классы должны быть закрыты для модификации и
открыты для расширения. Позволяет добавлять новую функциональность в
систему без необходимости изменения существующего кода. Основной способ
достижения – уменьшение сцепления классов, за счет вынесения сцепления на
абстрактный уровень. То использование зависимостей между конкретным
классом и абстрактным или интерфейсом
• Liskov Substitution Principle (LSP) – дочерние классы должны быть способны
заместить родительские классы. Конкретизация и следствие OCP, связан с
необходимость выполнения пред и пост условий при вызове методов дочерних
классов. На уровне языка в Java не поддерживается
• Dependency inversion principle (DIP) – зависимости должны быть от
абстракций, а не от конкретных реализаций. Фактически данный принцип
декларирует способ, которым достигается OCP.
• Interface segregation principle (ISP) – много специальных интерфейсов лучше,
чем один общий. Интерфейсы должны быть высокоспециализированные, а их
методы тесно сплоченные, связанные между собой. Роль интерфейса –
предоставление гибкости типу данных. Один интерфейс при этом фактически
представляет собой одну роль в приложении.
• Composite reuse principle (CRP) – предпочтение полиморфной композиции
перед наследованием. Предотвращает типичную ошибку – использование
наследования как первичного механизма повторного использования кода.
Наследование – более механизм генерализации, чем специализации.
Следовательно, добавлять поведение через родительский класс надо только
тогда, когда оно свойственно всем классам иерархии. В противном случае надо
реализовывать дополнительный интерфейс для конкретного класса или ветки
классов.
 • Principle of Least Knowledge (PLK) – операция над классом должна
использовать только объект класса, параметры, созданные операцией объекты
или содержащиеся в объекте класса сущности. НЕ должна непосредственно
использовать объекты, получаемые как ссылки посредством вызовов методов на
вышеперечисленных объектах. Достоинство – нет необходимости знать слишком
много о внутренней реализации объекта. Недостаток – появляется слишком
много мелких функций, просто пробрасывающих вызов. Альтернатива –
использование объектов, получаемых в качестве ссылок абстрактных типов, то
есть зависимость не от конкретной реализации, а от абстракции
• Зависимости пакетов
• Release reuse equivalence principle (REP) – ссылаясь на класс мы неявно
ссылаемся на весь пакет, его содержащий, имеем доступ ко всем классам в
пакете и можем неявно зависеть от них тоже. То есть гранулярность
использования эквивалентна гранулярности пакетирования.
• Common Closure Principle (CCP) – классы, которые изменяются вместе,
должны располагаться вместе, то есть в одном пакете
• Common reuse Principle (CReP) – классы, которые НЕ используются вместе НЕ
должны располагаться вместе. Обратное не верно - классы, которые вместе
используются отнюдь НЕ обязательно должны вместе изменяться и
следовательно располагаться в одном пакете
• Acyclic Dependencies principle (ADP) – зависимости между пакетами НЕ
должны быть циклическими. Выход – часть пакета выносится в отдельный
новый пакет, на который ссылаются оба старых, ранее связанных
зацикливающей ссылкой
• Stable Dependencies Principle (SDP) – зависимость должна быть в сторону
большей стабильности.
 Часто изменяющиеся пакеты менее стабильны, имеют меньше входных
зависимостей и больше зависят сами от других пакетов
 Редко изменяющиеся пакеты более стабильны, имеют больше входных
зависимостей и меньше зависят от других пакетов
o Stable abstraction principle (SAP) – стабильные пакеты более абстрактны, то есть
имеют больше абстрактных классов и интерфейсов, редко изменяются. От них все
зависят, а сами они мало зависят от остальных пакетов. Пакеты, включающие только
абстрактные классы, - основной источник проблем.

Требования уровня сервисов

• Фигурируют как capabilities – нефункциональные требования, описывающие качества
системы
• Performance
• Измеряется в виде времени отклика или в числе операций в единицу времени
• Метод достижения – выявление дорогих вызовов и контроль передачи информации
через границы подсистем
• Capacity(Вместимость)
• максимальное число процессов или пользователей обслуживаемых с требуемым
качеством
• измеряется как число транзакций в единицу времени
• измерение вместимости необходимо для того, чтобы добавлять ресурсы не раньше
того, как потребуется выйти на определенный уровень производительности с точки
зрения заказчика
• может измеряться как в системных параметрах, что легче но бессмысленнее, так и в
высокоуровневых параметрах, связанных с выполнением прикладных операций
• Flexibility(Гибкость)
 • Способность поддерживать изменения конфигурации программной и железной
• Производимые изменения должны быть прозрачны с точки зрения как клиентских,
так и серверных компонент
• Следствия способности к переконфигурированию - гибкость, надежность,
доступность растут, управляемость падает
• Измеряется во времени на месяц, потраченного на произведение обновления
системы
• Scalability (Масштабируемость)
• Возможность поддержки требуемого качества обслуживания (доступности и
производительности) при увеличении нагрузки на систему без изменения системы
• Scaling (масштабирование)
• Вертикальная
• Посредством увеличения числа процессов, памяти и т.д. на большом сервере,
в котором развернуты компоненты всех слоев
• Требует меньше изменений в архитектуре, ограничивается системными
ресурсами платформы
• увеличение эффективности внутрисистемных взаимодействий – управление
сессиями, пулинг ресурсов
• уменьшение гибкости, снижение стоимости обслуживания
• отказоустойчивость обеспечивается за счет обязательного объединения
нескольких больших вертикальных серверов в кластер
• Горизонтальная
• Обычно ряд отдельных машин на веб / J2EE слоях, разделенных файрволами,
входной балансир
• увеличивается число машин. Достигается за счет распределенного хранения
и балансирования запросов.
• Увеличение эффективности сетевого взаимодействия между серверами и
баланса загрузки
• Не подходит для машин с высокой интенсивностью взаимодействия между
слоями в частности по причине снижение латентности взаимодействия
• Увеличение гибкости и соответственно стоимости обслуживания
• Способы достижения
• Возможность корректной работы при загрузке процессора близкой к 100%
• Возможность добавления компонентов железа без разрушения системы
• Способность распределять задания по степени важности и при пиковой загрузке
выполнять только минимально необходимую
• Способность держать часть ресурсов в резерве
• Неожиданные пики нагрузки не лечатся закупкой железа
• Плохо спроектированные приложения вообще не способны увеличивать
производительность при возрастании числа и объема транзакций. Даже при
расширении железа
• Reliability (надежность)
• Сохранение целостности и согласованности приложения в целом и отдельных его
транзакций
• Требование надежности отрицательно влияет на достижение масштабируемости
• Измеряется в среднем времени наработки на отказ
• Если несколько компонент в параллель – метрики перемножаются
• Availability (доступность)
• Надежность способствует доступности, но в принципе система может быть
доступной даже если отдельные компонент не надежны и даже не работают
• Измеряется в «время простоя»/«время работы»
 • Extensibility (расширяемость)
• Возможность добавления дополнительной функциональности или изменения
существующей
• Не может быть измерена
• Средства – low coupling, interfaces, encapsulation – в общем тщательное
проектирование системы
• Maintainability (пригодность к ремонту)
• Возможность исправлять ошибки в одних частях системы не влияя на остальные ее
части
• Тоже не может быть измерена
• средства – low coupling, modularity, documentation
• Manageability (управляемость)
• Возможность управления системой в целях достижения остальных требований,
прежде всего доступности и производительности
• Связана с
• Возможность мониторинга системы с точки зрения удовлетворения остальных
требований
• Возможность изменения конфигурации системы для достижения остальных
требований без изменения самой системы
• Security
• Защита ресурсов – информации, сервисов, аппаратных и программных ресурсов
• Уровни
• Privacy – не раскрывать кому попало
• Integrity – логическая целостность и согласованность данных
• authenticity - пользователь тот, за кого себя выдает, сообщение получено ровно в
том виде, в котором отправлено
• availability - противодействие DoS атакам (= доступность)
• политика безопасности – как обеспечиваем, как противодействуем вторжениям, как
восстанавливаемся, базируется на анализе рисков и вычислении стоимости
• Validity – способность тестироваться, то есть предсказуемость результатов, стабильно
получаемых при одном и том же наборе входных данных

Двухзвенная архитектура
• Применяется экстенсивно, обычно в некритических приложениях с
• несложной обработкой данных,
• легкими транзакциями
• гомогенная среда с небольшой загрузкой сети
• бизнес правила обработки данных изменяются редко
• не более 100 пользователей
• Ограничения
• Scalability – благодаря тому, что каждый пользователь получает собственную
сессию. Так как она поддерживается постоянно, то сеть забивается «пустыми»
запросами. Использование хранимых процедур дополнительно снижает сабж,
потому что требует от БД дополнительной производительности. При запуске
больших задач обновления данных (batch) клиент ожидает, хотя работа происходит
на сервере.
• Interoperability – сложные операции на сервере за счет хранимых процедур
требуют использование специфических для баз языков, которые не только разные,
но и зачастую не имеют способа интеграции друг с другом. Отсутствие средств
разработки и тестирования для них
 • Administration & configuration – обновления должны доставляться и
устанавливаться для каждого пользователя отдельно, у них разные конфигурации,
дополнительная нагрузка на администраторов.

Трехзвенная архитектура
• Плюсы
• Изменения в одном слое не зависят от изменений в других слоях
• Загрузка сети минимальна, так как основные потоки данных внутри звеньев
• Бизнес изменения не влекут за собой изменения клиентов, легче обновлять
систему
• Клиент изолирован от подробностей того, кто и сколько серверов обрабатывает
данные
• Пул соединений с БД может совместно использоваться многими клиентами,
меньше стоимость лицензий, меньше зависимость от специфики БД, в частности
от хранимых процедур
• Бизнес логика пишется на стандартных языках и не завязана на специфику БД
• сервер приложений
• Поддержание связности данных в распределенном приложении за счет
блокировки, транзакций и репликации
• Сервисы управления процессами – разработка, запуск, мониторинг и разделение
ресурсов
• облегчает все на свете за счет централизации прикладной логики процессов
• поддерживает распределенные транзакции и асинхронные очереди обработки
для обеспечения надежности транзакционной обработки данных
• предоставляет ресурсы, основываясь на их логических именах, а не на
местоположении
• Уровни
• Клиентский
• взаимодействие с сервером по HTTP, JRMP, RMI-IIOP, IIOP
• мобильные приложения, апплеты, браузер, одиночные Java приложения,
загруженные по WebStart, веб-сервис, устройства со встроенной Java
• Представления
• сервлеты и JSP/JSF страницы производящие GUI, сервлеты реализующие веб
сервисы
• функции – обработка запросов, поддержка сессии, осуществление
аутентификации и SSO, доставка данных, вызов бизнес компонент и
изоляция их от типа клиентских приложений
• взаимодействие с сервером по RMI, EJB, CORBA
• Бизнес
• Возможно, особенно для устаревших систем, чтобы некоторые бизнес
модули шли сразу на уровень ресурсов, минуя интеграционные API
• CORBA объекты также могут располагаться на бизнес уровне и быть
доступны для Java приложений
• Основной вопрос, располагать бизнес уровень вместе с презентационным или
отдельно.
• Вместе – быстрее и проще, но менее масштабируемо горизонтально.
• Отдельно – сложнее, особенно передача транзакционного и безопасности
контекста, но потенциально более масштабируемо и отказоустойчиво
• Интеграционный
• часто не выделяется как отдельный, например JDBC / JCA + домен задачи
• служит для обеспечения взаимодействия с EIS, базой данных, устарелыми
информационными системами, B2B и платежными и так далее
 • Ресурсов
• Enterprise Information Service (EIS) – обобщенный термин для систем данного
уровня, метод доступа - JCA
• Соображения, влияющие на выбор клиента
• Сеть – не нулевая латентность, ограниченная пропускная способность, не всегда
надежна
• Безопасность
• Наличие firewall, не пропускающих IIOP протокола
• Сложность идентификации / аутентификации в много доменных средах.
Liverty Allicance призван решить проблему SSO в данной ситуации
• Необходимость инсталляции или автоматическое обновления
• Для тонкого клиента
• интернет браузер есть везде
• Возможности построения пользовательского интерфейса
• Интерфейс тонкого клиента (ТК) всем понятен и привычен
• ТК имеет ограниченные возможности и несовместим между различными
обозревателями, особенно сложный
• ТК производит много соединений с сервером, данных перекачивается
больше, так как вместе с данными идет и код интерфейса
• Проверка пользовательского ввода
• Негативно влияет на пропускную способность сети, так как
перекачивается еще и дополнительный код / данные. Выход –
использование <script> элементов, позволяющих кэширование скриптов
• EJB/EIS слои не должны полагаться на пользовательскую проверку и
проверять данные сами – частичное двойное кодирование проверки
данных
• Протокол взаимодействия с сервером
• Управление сессионным состояние
• Сессия – коротко живущая последовательность связанных запросов
одного пользователя к одному серверу. Состояние сессии – порция
данных, относящаяся к сессии в целом, а не к отдельным запросам
• Поддержка – куки и переписывание ссылок. Могут быть изменены
клиентом и потому нежелательны, лучше куки – ключи к серверной
сессии
• Для толстого клиента
• Типы
• Приложение – установленное или загружаемое через Web Start
• Апплет
• MIDlet
• Платформа Mobile Information Device Profile (MIDP)
• Вместе в архивом идет JAD файл описателя
• Так как гоним только данные и только тогда, когда выполняются операции –
меньше нагрузка на сеть, как по объему, так и по частоте запросов
• Могут соединяться с сервером
• Через интернет протоколы – на веб уровень
• Могут посылать / принимать сообщения в любом формате и гибко
использовать HTTP
• Длинная цепочка обработки: действие пользователя, HTTP запрос,
событие в веб слое, обработчик события, генерация ответа, его
передача, преобразование ответа в обновление интерфейса
• Через RMI/IIP – на бизнес уровень
 • только апплеты и приложения. Мобильные клиенты такой
возможностью не обладают
• файрволы режут трафик, предпочтительно для гетерогенных сред
• требуют клиентского контейнера, предоставляемого производителем
сервера в виде набора библиотек и предоставляющего JMS / JTA /
JDBC API
• развертывание, обновление, поведение клиента не определяется
спецификацией
• Через специальные – на EIS уровень
• Необходимость вынесения части логики в клиента – сложно
поддерживать несколько типов клиентов, обновлять и так далее
• Сами хранят данные сессии, могут возникать конфликт с актуальными
данными в системе
• Логика проверка данных должна быть расположена и на клиенте и на
сервере, но можно частично избежать дублирования кода

J2EE обзор
общие идеи
• платформа для построения распределенных приложений, именно в распределенности и
многослойности приложений основное отличие от J2SE
• J2EE раскладывается на отдельные части: платформа, стандартная реализация, тест на
совместимость, Application Programming Model (APM) Blueprint
• Необходима для приложений, которым надо: распределенность, транзакции,
безопасность, правление ресурсами
• J2EE компонент – самодостаточный функциональный модуль, встроенный в J2EE
приложение, содержащий необходимые классы и другие файлы, и взаимодействующий
с остальным компонентами
• Преимущества
• Повторное использование решений дизайна и кода
• Прозрачная функциональная декомпозиция на компоненты с ограниченной и четко
определенной ролью
• Задачи по разработке хорошо распределяются между участниками с различными
ответственностями и уровнями
• Классы, частота изменений которых сильно различаются, разделяются по разным
компонентам и слоям
• Расширяемость
• Модульность
• Единая вертикальная безопасность от входного GUI до EIS системы
• Минимизация сетевого трафика за счет ограничения объема данных, передаваемого
по сети и локализации основного информационного взаимодействия внутри
контейнеров
• Согласованность данных системы за счет прозрачности всех компонентов для
проводимой транзакции
• Переносимость между различными серверами приложений и используемым ПО
среднего уровня (middleware). Минимизация привязки к вендору
• Стандартизация API и шаблонов взаимодействия с основными инфраструктурными
сервисами
• Концепции и API разрабатываются и одобряются совместно, как вендорами, так и
сообществом разработчиков
 • Защита сделанных инвестиций: разрабатываемое ПО с одной стороны легко может
быть интегрировано с уже имеющимися решениями, с другой доступно широкому
диапазону будущих систем вне зависимости от их языка и платформы
• Безопасность
• Целостность данных – MAC, message authentication check
• Confidentiality - конфиденциальность
• Nonrepudiation – неотрекаемость
• Auditing – аудит выполняемых операций

Стандартные роли
• Entity Enterprise Bean Developer
• Bean Developer
• Устанавливает транзакционные атрибуты
• Программный контроль безопасности
• Application assembler
• Может быть бизнес аналитиком верхнего уровня, представляющим себе приложение
в целом
• Добавление ролей и декларативный контроль безопасности
• Определяет ссылки отдельных бинов на
• Пулы соединений с БД
• Почтовые сессии
• URL соединений
• JMS очереди и топики
• Другие бины
• Bean Deployer
• Должен быть администратором БД и сервера приложений
• Связывает описания с реальными таблицами в БД, пользователями, ролями
• Component Provider – предоставляет вспомогательные компоненты всем остальным
• Application Server Provider
• EJB Container Provider

API
• J2SE, JDBC
• RMI-JRMP, RMI-IIOP – RMI нативное и поверх Corba
• Java IDL (Interface Definition Language) – поддержка Corba
• EJB, Servlets, JSP, JTA
• JMS
• Connector архитектура 2.0 предоставляет стандарт включения JMS provider в сервер
приложений, подобно адаптеру ресурсов
• JAF – на основе определения типа данных сокрытие методов работы с данными,
исследование операций, поддерживаемых для данных, получение бинов,
поддерживающих эти операции. Пример – создание объекта для работы с данными на
основе Mime типа
• Java Mail – две части: пользовательский интерфейс и провайдер сервиса. В стандарте
предоставляется сервис работы с сообщениями через Internet протоколы. Работа с
данными основывается на JAF и их MIME типе
• JSF – новая модель построения веб интерфейса, базирующаяся на классической
• Гибкая модель формирования интерфейса из компонент, которые
отрисовываются при помощи Renderer. Набор последних составляет RenderKit,
который ориентирован на какой-то тип клиента. Стандартный поддерживает HTML
4.01
 • Возможности: проверка вводимых данных, обработка событий, перенос данных
между моделью и компонентами, создание и управление объектами модели,
поддержка навигации
• JAXP – набор API для работы с XML. Включает в себя DOM, SAX, XSLT средства
• JAXB – перенос данных между XML и бинами на основе схемы
• JAX-WS – доступ и реализация веб сервисов. Реализация возможна как на основе
сервлетов, так и посредством EJB. Кроме JAXP использует следующие API
• SAAJ – низкоуровневое API, реализация SOAP поверх HTTP. В частности работа с
бинарными вложениями в сообщениях. Используется в JAX-WS и JAXR
• JAXR – работа с реестрами, в частности с UDDI
• JCA – используется производителями и системными интеграторами для создания
адаптеров, используемых в составе J2EE приложений для доступа к сторонним
ресурсам. Основная задача – реализация Recource Manager, в частности для включения
предоставляемых операций в транзакцию. JCA + веб сервисы = основное средств
системной интеграции
• JPA - ORM средство, компоненты: API, работа с запросами, метаданные
• JNDI – унифицированная работа с LDAP, NDS, DNS, NIS, AD и т.д.
• JAAS – безопасность, Java версия Pluggable Authentication Module (PAM) архитектуры,
позволяющей включать пользовательские модули в систему авторизации

Протоколы
• TCP/IP. Первый над вторым, добавляет гарантированную доставку сообщения,
контроль очередности, времени доставки и так далее. Добавляется понятие
«соединения»
• HTTP(S)
• SSL – серверы аутентифицируются всегда, клиенты опционально
• JRMP – взаимодействие между двумя JVM, на сервер должен быть поднят RMIRegistry
• Object Management Group (OMG) протоколы
• Java IDL – позволяет Java клиентам вызывать операции над Corba объектами,
которые предоставляют описание своих интерфейсов. Специальный компилятор
генерирует Java стаб для адресуемого объекта
• RMI-IIOP – позволяет конвертировать удаленный интерфейс в IDL описание,
предоставляемое Corba клиентам
• Взаимодействие с COM – через COM/CORBA шлюз, соответственно COM <-> EJB

Контейнеры
• Java application client container
• Предоставляется производителем сервера приложений
• Поддерживается - J2SE, JDBC, JMS, JNDI, RMI-IIOP
• Отличается от просто развернутого клиентского приложения тем, что содержится
внутри EAR и развертывается средствами сервера приложений
• Клиентский контейнер поддерживает все клиентские модуля из одного приложения
• Applets container
• Предоставляется производителем браузера
• Поддерживается - J2SE
• Web container
• Компоненты – сервлеты, JSP, JSF
• Поддерживается - J2SE, JDBC, JMS, JNDI, RMI-IIOP, JTA, Java Mail, JAF
• Иерархия контейнеров
• Сервлетный – поддержка HTTP и опционально HTTPS
• JSP – то же, плюс …
 • Web – то же, плюс предоставление доступа к J2EE сервисам и
коммуникационному API
• EJB container
• JEE Compatibility Test Suite (CTS) - проверяется совместимость приложения с
платформой JEE
• Java Conformance Kit (JCK) – дополнительные проверки не покрываемые CTS, плюс
эталонные приложения для проверки самой платформы

EJB
• Если приложению не нужна безопасность или транзакции, то надо задуматься о
применимости EJB
• Home (EJBHome) интерфейс – фабрика создания, удаленные (EJBObject) – прокси
• Entity бины
• позволяют расшаривать информацию между различными пользователями
• конкурентно используются
• Statefull
• хранить информацию ОДНОГО пользователя между отдельными запросами
• конкурентный доступ НЕ поддерживается
• DAO для BMP бинов позволяют уменьшить зацепление с SQL запросами

Транзакции
• Обеспечивают целостное состояние данных путем контроля за операциями по их
обновлению
• Required – дефолтный
• requiresNew – когда метод должен быть закомичен вне зависимости от любых условий
• notSupported – когда менеджер задействованного в операции ресурса не поддерживает
транзакции
• supports, mandatory, never – рекомендуется не использовать вовсе
• Сервлет может начать UserTransaction, она не может переходить границу HTTP вызова
• В JEE окружении рекомендуется начинать транзакции на вызове фасадного сессионного
бина (там же и безопасность контролировать, кстати)

Документирование архитектуры
Общие идеи
• Объектно Ориентированный Анализ (ООА) – исследование, анализ и спецификация
требований в терминах объектов, сообщений, классов, наследования, полиморфизма
• Объектно Ориентированный Дизайн (ОАД) – дизайн приложения в терминах классов,
объектов, фреймворков и их взаимодействия
• Назначение модели
• Визуализация системы в состоянии как есть или как требуется
• Спецификация структуры или поведения
• Предоставление шаблона в качестве руководства по построению системы
• Документирование принятых решений
• Основные типы документов
• System Requirements – диаграммы use-cases, object, sequence / collaboration, activity
• System Architecture – диаграммы class, package, component, deployment, statechart
Жизненный цикл приложения
• RUP – инкрементальный процесс, используемый менеджерами для управления
софтварными пректами. Вся разработка разделена на итерации, те на фазы. Разделение
на итерации снижает риск
• Это фреймворк ориентированный на менеджеров и руководителей, а не на
архитекторов и разработчиков
• Этапы
• Interception – просмотр проекта в целом, анализ контекста
• Elaboration – уточнение, анализ требований и построение архитектуры
• Construction – построение приложения
• Transition – внедрение, передача пользователям
• Этапы ЖЦ
• Анализ
• Анализ требований – сбор и детализация требований, а также внешних
характеристик системы. Формирование плана проверки соответствия системы
набору требований
• Анализ системного контекста - определение контекста системы через варианты
использования и сценарии. Перечисление внешних событий, сообщений и
действий. Система трактуется как черный ящик. Для систем реального времени
определяются характеристики и описаний синхронизации для обработке
запросов
• Формирование модели – идентификация классов, объектов, их ассоциаций для
решения конкретных проблем. Используются диаграммы классов, состояний,
последовательностей и сотрудничества. Формируется приложение в виде
декомпозиции основных подсистем на высокоуровневые классы
• Дизайн
• Архитектурный – представление
• физической архитектуры в виде диаграмм развертывания и компонентов.
• Конкурентной архитектуры – используются диаграммы классов активных
объектов
На данном этапе используются шаблоны проектирования. Кроме того
выполняется привязка абстрактной архитектуры к конкретному железу и БПО
• Механистический – определение поведения классов и объектов в процессе
сотрудничества. Используются диаграммы последовательностей и
сотрудничества, дорабатываются созданные на предыдущих этапах, особенно
диаграммы состояний
• Детальный – детальное поведение и структура основных классов
• Разработка
• Внедрение
• Unit тестирование – внутренней структуры и поведения классов
• Интеграционное тестирование – различные компоненты во взаимодействии
между собой
• Проверочное тестирование – на соответствие плану проверки на этапе анализа
• Поставка – включая развертывание, документирование, обучение пользователей
и т.д.

Структура UML
• Представления системы посредством UML
• Дизайнерское - классы и пакеты
• Процессное – состояния, активности, последовательности и сотрудничества
 • Компонентное
• Развертывания
• Прецедентов использования
• Блоки
• Элементы
• Структурные
• Классы
• Операции записываются как - метод (аргументы) : тип результата
• Видимость – “+-#”
• Интерфейсы – реализуются классами или компонентами
• Пакеты – коллекция классов со сходной функциональностью, могут
вкладываться друг в друга, внешние пакеты также зовут доменами
• Взаимодействие (collaboration) – комбинация и взаимодействие ролей и
других элементов, образующих совместно нечто большее, чем сумма
отдельных элементов
• Прецеденты (use cases).
• Законченные фрагменты функциональности, поставляемые как системой
в целом, так и отдельными классами
• Могут быть
• essential – основные, свободны от подробностей реализации, важны на
начальных этапах проекта, иллюстрируют и документируют бизнес
процесс
• real – сформулированы в терминах конкретной архитектуры и дизайна,
поясняют как именно поддерживаются и реализуются бизнес
процессы
• В качестве акторов, могут выступать и подсистемы тоже. Важно, что они
ЗА границами системы.
• От прецедентов могут идти стрелки взаимодействия к другим акторам
• Активные классы
• Компоненты – выделенные заменяемые части системы
• Ноды – физические объекты, реализующие некоторую вычислительную
активность. Как минимум обладают памятью, иногда специфицируются
совместимостью с каким-то стандартом. Например, веб сервером или
сервером приложений. Могут поставлять ряд интерфейсов
• Состояние – условие, которое может встречаться в течении жизненного
цикла объекта. В нем может удовлетворять ряду условий, выполнять какие-то
действия или ждать чего-то. Могут вкладываться друг в друга
• Поведенческие
• Взаимодействие
• Машины состояний
• Группировки
• Единственный элемент - пакет
• Аннотации
• Единственный элемент – собственно аннотация
• Отношения
• Зависимость (dependency)
• Ассоциация – для выполнения своих функций один объект знает о наличии
другого
• По умолчанию двунаправленная, если есть стрелка – однонаправленная от
стороны, содержащей переменную связи
 • Агрегация (ромб на стороне целого) один хранит коллекцию ссылок на
другого
• Композиция (ромб закрашенный) – один включает как неотъемлемую часть
других
• Обобщение (наследование для классов)
• Наследование с пустой стрелкой
• Реализация (реализация интерфейса)
• она же улучшение (refinement) – наследование со стереотипом
• наследование со сплошной стрелкой
• Диаграммы
• Статическое представление
• Прецедентов (акторы и прецеденты)
• Проблемно центрированный взгляд на систему
• Модель системы с точки зрения верхнего бизнес уровня
• Прецедент – функция или сервис системы с точки зрения внешнего
наблюдателя. Актор – представление роли по отношению к системе
• Один прецедент может быть обобщением другого или его специальной
версией
• Используются в основном когда
• Определяются требования
• Взаимодействуем с клиентами
• Тестируем систему
• Классов (классы, интерфейсы, взаимодействия и их отношения).
• Static design view
• Если активные классы, то это статическое представление процессов
системы
• Может включать пакеты
• Пакетов – представляет структуры системы в виде групп. Часто в виде
пакетов представляются подсистемы, используется соответствующий
стереотип
• Компонентная – статическая диаграмма реализации системы
• Развертывания
• Соответствует компонентной – распределение по нодам
• Только компоненты, которые представлены работающими артефактами
• Динамическое представление
• Последовательностей
• подчеркивает упорядоченность во времени,
• «Return» взаимодействия по умолчанию не показываются
• Прямоугольник активации показывает время, задействованное на
обработку сообщения
• асинхронные сообщения – полустрелка, синхронные – залитая стрелка,
остальные – не важно
• временно упорядоченный взгляд на систему
• Сотрудничества
• структурную организацию источников и адресатов сообщений
• упорядоченность сообщений показывается как их иерархические номера
• процедурный взгляд на систему
• Состояний
• Состоит из состояний, входных и выходных переходов и условий,
наложенных на переходы
• иллюстрирует управляемое событиями поведение одного объекта
 • смена состояний запускается внешним воздействием, например
поступлением сообщений
• активностей
• поток управления внутри объекта в целом
• большинство активностей запускаются окончанием предыдущих, то есть
внутренним воздействием
• Правила их комбинирования
• Основные механизмы
• Спецификации
• Украшение (adornment) – символы видимости членов класса -+#
• Разделители (divisions) – «:» и подчеркивание в наименованиях
• Расширения
• Стереотипы
• Помеченные значения
• ограничения

Шаблоны проектирования
общее
• представляют решения для повторяющихся проблем в каком-то контексте, состоят из
формулировки проблемы и последовательности действий по решению
• идентифицируют проблему и документируют решение в форме, которая наилучшим
образом подходит для распространения, понимания и обсуждения
• составляют общий язык, подходящий для обсуждения дизайна системы
• концентрируют и документируют знания, составляющие Best practice для какого-то
предметного домена
• Позволяют обсуждать решения в терминах ограничения, влияния на систему и баланса
возможностей и проблем
• В J2EE фреймворк входят
• Прокси – для удаленных интерфейсов бинов
• Декоратор – для EJBObject
• Factory Method / Abstract Factory – для Home интерфейсов бинов, удаленных и
локальных
• Best practice
• используется для дизайна на уровне компонентов, например использование
сессионного бина в качестве фасада приложения
• схема оптимального осуществления какого-то процесса, испробованная в ряде
ситуаций
• проходит через все сценарии
• guideline
• общая идея, применяемая вообще, например минимизация трафика за счет
увеличения гранулярности запросов
• отражает соглашения или общие идеи, принятые сообществом разработчиков. Как
формальные стандарты, так и неформальные но общепринятые идеи

MVC
• Модель представляет клиентам разные API.
• Представлению - для считывания данных и подписки на события
• контроллеру – для вызова бизнес методов
• На модель возлагается также ответственность за сохранение и считывание данных
из базы
 • Множественность контроллеров, каждый обслуживает один прецедент или группу
прецедентов, связанных общей функциональностью
• Для обеспечения повторной используемости частей шаблона
• Модель ничего не должна знать про интерфейс и контроллер
• Контроллер делится на две части – зависящую от протокола и абстрактную.
• В веб приложении в сервлет лучше не помещать бизнес код, оставляя его
бизнес бинам. Те в свою очередь ничего не знают о технологии интерфейса
• Аналогично для Swing приложений – слушатели элементов интерфейса не
должны содержать прикладного кода
• Преимущества
• Одни и те же данные могут быть представлены в различных видах
• Упрощается анализ зависимостей между частями, улучшается расширяемость
• Улучшается инкапсуляция данных за счет выделения хорошо ограниченного API
• В распределенном приложении появляется хорошо определенные границы
разделения по слоям. Модель – бины данных / сессионные бины, контроллер –
сервлеты, представления – JSP страницы
• Фрагменты приложения могут разрабатываться, развертываться и обновляться
по частям, не влияя друг на друга
• Хорошее разделение разработчиков по ролям относительно частей шаблона
• При сохранении ограниченных интерфейсов взаимодействия каждая часть
заменяема, увеличивается гибкость приложения
• Улучшается тестируемость, модель и контроллер могут быть протестированы в
юнит манере без необходимости эмулировать использование интерфейса.
Интерфейс может быть протестирован с «затычкой» вместо модели
• Модель обеспечивает согласованность данных системы за счет контроля над их
изменениями.
• Недостатки
• Части не могут использовать подробностей внутренней реализации друг друга.
Появляются длинные вызовы и падает производительность. Лечится тщательным
проектированием API
• В распределенной системе из-за большого объема передаваемых данных могут
появляться задержки реакции. Лечится производительностью БД и сервера
приложений
• Стабильность интерфейсов модели данных – критичный элемент применимости
шаблона. И представление и контроллер пишутся в терминах модели данных.
Частично лечится переводом взаимодействия контроллер – модель на шаблон
команды, содержащей в себе все необходимые данные вызова. К сожалению, может
частично связывать модель со структурой интерфейса

Best Practices
• Для уровня представления
• Отделение HTML от Java. В JSP не должно быть кода, только теги и шаблоны
• Вынесение бизнес логики в бины
• Выносить прикладную логику из тегов
• Различать динамическое и статическое включение
• использование таблиц стилей вместо кодирования визуальных свойств элементов
интерфейсов
• использование MVC, например Struts, Tapestry, WebWork
• использование библиотек тэгов
• использование JSP комментариев – не попадают клиенту и не грузят сеть
• использование JSP механизмов безопасности и перехвата исключений
• Для JEE уровня
 • Использование DAO и Value Object
• Использование сессионного фасада для сокрытия подробностей взаимодействия
бинов друг с другом и предотвращения лишних сетевых вызово
• Использование принципа master-detail
• Если операция изменила дочерний объект на сервере, то он должен быть
доставлен мастер объекту на клиенте
• Логика наполнения мастер объекта дочерними должна быть вынесена из
клиента
• Кэширование
• Кэширование результатов поиска компонентов и данных, используемых
повторно или разделяемых между клиентами
• Разделение данных между пользователями возможно, когда данные сильно
чаще читаются, чем пишутся. Если пишутся – пользователю в этот момент
выделятся отдельный объект
• Не делать кэш пока не известно, кто и когда его будет чистить
• Полезно кэшировать полученные ссылки на EJBHome
• Не использовать EJB пока нет нужды в использовании инфраструктурных
сервисах контейнера
• Стараться использовать локальные интерфейсы бинов
• Объединение нескольких сетевых вызовов в один, шаблон команды
• При сериализации убирать ненужные данных за счет «transient»
• По возможности не использовать транзакции, за счет атрибутов NotSupported /
Never. Транзакции должны включать в себя минимальный объем операций и
данных
• Просто по производительность
• Архивирование данных, передаваемых по сети, снижение количества сетевых
запросов
• Минимизация объема клиентской сессии
• Утечки памяти надо ловить ДО изменения скорости выполнения
• В процессе тестирования измеряется
• Достижимость 100% загрузки процессора
• отклик при 100% загрузки процессора
• поведение при увеличении количества пользователей и частоте их
запросов
• лучше оптимизировать один тяжелый часто используемый метод, чем много
маленьких или редко используемых
• Для EIS уровня
• Использование главным образом средств, предоставляемых вендором
• Формирование домена объектов доступа, скрывающих сложность используемой
системы.
• Объекты доступа должны проектироваться вне зависимости от
предположений для каких задач и в каком окружении они должны
использоваться, чтобы обеспечить использование кода.
• Не рекомендуется включение в объекты логики транзакции и безопасности
• Получение и высвобождение соединений должно производиться в одном методе,
не выходя за границы исполняемого кода
• Небольшое количество соединений должно совместно использоваться
клиентами, некоторые JDBC драйвера вообще не поддерживают множественные
соединения с БД
J2EE
• Области применения (кроме вышеперечисленных)
• Презентационный слой – декоратор, входной контроллер, хелпер представления,
композит, service to worker, dispatcher view
• Бизнес слой – бизнес делегат, объект-значение, сессионный фасад, сложная
сущность, сборщик объектов значений, value list handler, service locator
• Интеграционный слой – DAO, Service activator
• Intercepting filter
• Необходимость перехвата и обработки запроса перед и после того, как он будет
обработан
• Реализация централизованной общей логики над всеми запросами
• Пост / пред обработка компонентами, слабо связанными друг с другом и с
получателем
• возможность на ходу конфигурировать их перечень и порядок соединения
• Части шаблона – клиент, менеджер фильтров, цепочка фильтров, фильтры,
компонент – получатель
• Применимость шаблона ограничивается объемом данных, которые должны
совместно использоваться несколькими фильтрами
• Front controller
• Централизованная точка доступа к презентационному уровню, чтобы
• Отделение механизма обработки запросов от бизнес-процессов
• избежать дублирования логики обработки запросов за счет вынесения из
представлений неизбежно дублируемого там кода маршрутизации и управления
запросами
• применять одни и те же процессы обработки к запросам разных типов
• отделить системную обработку запросов от реализации представлений. Вплоть
до изоляции представлений от протокола обмена
• разделить ответственности разработчиков логики и разработчиков
презентационного слоя
• поддержка централизованной политики контроля доступа
• Части шаблона – клиент, входной контроллер, контроллер приложения, обработчик
запроса, представление
• Входной контроллер использует контроллер приложения для
• Управление обработчиками – создание, вызов для обработки запроса
• Управление представлениями – поиск, создание, вызов для обработки
запроса
• Context object
• Необходимость отделения системы от ее части, специфической для используемых
низкоуровневых протоколов
• Есть компоненты и сервисы, которым нужен доступ к низкоуровневой
информации
• Хочется предоставить им некоторую ее часть, абстрагировав от API доступа и
прочих системных деталей.
• В том числе отбросив ненужные подробности
• Изолировав систему от изменений в протоколе
• Части шаблона – клиент, фабрика контекста, интерфейс протокола, контекст
• Система создает и предоставляет интерфейс протокола
• Клиент обращается к фабрике, которая
• создает контекст и связывает его с протоколом
• возвращает контекст клиенту
 • клиент за счет обращения к методам контекста получает доступ к системным
данным
• задача контекста – предоставление общего доступа к системной информации в
системно не зависимом виде, снижение зависимости между прикладной логикой и
системным уровнем.
• Контекст предоставляет клиенту состояние инфраструктурного уровня системы
• Проще тестировать – можно гонять тесты, подсовывая фиктивный контекст.
Например, эмулирующий веб сервер или сервер приложений
• Снижается производительность, так как возникает дополнительный слой доступа к
базовому системному функционалу
• Application controller
• Необходимость централизованного управления действиями и представлениями, а
также разделения данной задачи на отдельные модули
• Необходимость повторного использования кода действий и управления
представлениями
• Постепенное наращивание функциональности приложения по частям
• Необходимость тестирования механизма обработки запросов вне веб контейнера
• Части шаблона – контроллер приложения, mapper, map, обработчик (действие или
представление)
• Mapper – ищет соответствующую map и на ее основе создает обработчик
• Контроллер получает от mapper обработчик и передает ему запрос
• Может, как входить в состав входного контроллера, так и выделяться, чтобы
абстрагироваться от системных подробностей в виде протокола доступа клиента.
• Возможность независимого тестирования, так как входные запросы уже развязаны
от среды и протокола
• Обеспечивает независимость от подробностей организации сетевого уровня и
используемого протокола уровня приложения
• View helper
• Отделение представления от логики его формирования
• Использование шаблонов
• Удаление кода из представления
• Разделение работы разработчиков и дизайнеров
• Части шаблона – клиент, представление, хелпер (например тег или POJO класс),
хелпер, модель данных
• Представление обращается к хелперу уже для получения данных в
презентабельном виде
• Хелпер преобразует данных из модели в презентабельный вид
• Средство повторного использования логики формирования представления на основе
шаблона, а также удаления дублирующего кода из представлений
• Облегчает разделение ролей – отдельно дизайнеры страниц, отдельно разработчики
представлений данных
• Легче тестировать, так как хелперы можно запускать отдельно от страниц, к тому же
их меньше
• Основная ошибка применения шаблона – использование хелперов как дублирования
скриплетов, например теги условия или итерации.
• Composite view
• Построение представление из отдельных элементарных модулей, раздельное
управление содержанием и структурой
• Использование одних и тех же фрагментов в разных представлениях
• Содержание фрагментов может часто меняться в зависимости, например, от
уровня доступа пользователя, его роли и т.д.
 • Необходимость избежать прямого включения и дублирования повторяющихся
фрагментов во множестве представлений – легче управлять и перестраивать
шаблоны представления
• Тем не менее зачастую система становится и сложнее для обслуживания, так как
отдельные фрагменты оказываются завязанными между собой и с контекстом –
потенциальный источник ошибок
• Части шаблона – представление, менеджер представления, шаблон составного
представления, составное представление, элементарные представления
• Часто используется для представления перечня ошибок, под-представлений и
фиксированных разделов страниц
• На сборку конечного результата тратится время и проседает производительность,
лечится выполнением сборки на этапе компиляции
• Service to worker
• Ядро подсистемы обработки запросов, позволяющее выполнить логику запроса
ПЕРЕД тем, как передать управление представлению
• Используется специальная логика генерации динамического содержимого
представления
• Может использовать несколько представлений, в зависимости от результата
обработки запроса
• Необходимость использования какой-то библиотеки в приложении
• Части шаблона – входной контроллер, бизнес помощник, бизнес сервис, модель
данных, контроллер приложения, представление, хелпер представления, который
обращается к модели данных
• Основное отличие от маршрутизирующего представления – логика выполняется
перед определением необходимого представления
• Лучше разделение ответственностей разработчиков
• Dispatcher view
• Тоже отделение представление от модели данных и логики обработки, но запрос на
обработку идет изнутри представления
• Необходимо обработать запрос с выполнением минимального количества бизнес
операций
• Наличие статических представлений или представления, работающего со
статической моделью данных
• Выбор представления НЕ зависит от результата обработки запроса
• Части шаблона – входной контроллер, контроллер приложения, представление,
бизнес хелпер, бизнес сервис, модель данных, хелпер представления, который опять-
таки идет к модели данных
• Стандартный путь использования третьих библиотек, которые предоставляют
адаптеры представлений и трансформеры данных. Например, JSTL
• Необходимо минимизировать количество кода по обработки данных внутри
представления
• Business delegate
• Необходимость скрыть от клиента сложность бизнес уровня, а также подробности
взаимодействия с ним
• Располагается на уровне презентации, пробрасывает запросы к бизнес уровню
• Используется для минимизации связывания между этими двумя уровня,
защищает представление от изменений в бизнес интерфейсах
• Предупреждает избыточные вызовы бизнес сервисов за счет кэширования
данных
• Преобразует сетевые и инфраструктурные исключения в прикладные
• Скрывает от клиента системные подробности - детали поиска сервиса,
конфигурирования и вызова
 • Скрывает от клиента подробности реализации сервиса
• Части шаблона – представитель бизнеса, локатор сервиса, бизнес сервис, хэндлер
(создается локатором, кэшируется, его ид возвращается клиенту)
• Может использоваться для
• частичного восстановления после полученной от сервиса ошибки, скрывая ее от
клиента
• кэширования данных – уменьшая нагрузку на сеть
• скрывать место и способ действительной реализации сервиса – способ
варьирования развертывания
• Service locator
• Необходимость прозрачно обращаться к компонентам бизнес уровня
• Независимость от
• API поиска в регистре, например JNDI
• EJB методов поиска
• Централизация логики поиска компонентов бизнес уровня
• Снижение вычислительной нагрузки за счет
• исключения множественного повторного создания начального контекста и
поиска в нем сервиса.
• Кэширования получаемой информации, например WSDL файлов
• Восстановление соединения с ранее используемым сервисом при помощи
хэндлера
• Возможность пакетирования запросов на поиск и соединение с удаленными
сервисами – снижение нагрузки на сеть
• Части шаблона – локатор сервиса, контекст реестра сервисов, кэш, реестр сервисов,
бизнес сервис
• В системе может их быть две штуки, один на сервере и один на клиенте
• Session façade
• Предоставление бизнес сервисов клиентам, контроль пользовательского доступа,
безопасность, снижение сетевого трафика и изменение гранулярности интерфейсов
• изоляция клиента от подробностей реализации бизнес компонентов и домена
проблемы, уменьшение связывания клиента с сервером, снижение сложности
клиента
• выделение, централизация и укрупнение фрагментов логики, предоставляемой
клиентам
• сокрытие от клиентов подробностей взаимодействия между отдельными
сервисами при вычислении конечного результата
• единая точка реализации общесистемных сервисов – транзакции, безопасность,
жизненный цикл
• Части шаблона – сессионный фасад, бизнес сервис, бизнес объект, DAO объект
• Часто для каждого бизнес-делегата на клиенте создается свой сессионный фасад на
сервере. Сессионный фасад реализует бизнес логику над одним / несколькими
сервисами приложений, изолируя клиента от знания подробностей их связи между
собой
• Описывается как единая входная точка совместного доступа к «entity beans»
• Application service
• Выделение ключевой бизнес логики из массы различных бизнес компонентов и
сервисов
• Минимизация бизнес логики в сессионном фасаде
• Использование бизнес логики, основанной на нескольких бизнес объектах или
других сервисов.
• Укрупнение API, изоляция клиента от необходимости понимания связей между
отдельными бизнес объектами
 • Локализация реализации отдельных вариантов использования
• Повторное использование бизнес логики
• Части шаблона – клиент, контроллер приложения, фабрика команд, команда, сервис
приложения
• Реализация отдельного сервиса приложения – способ снижения сцепления бизнес
объектов друг с другом.
• Выделение логики уровня приложения в отдельный объект
• Business object
• Формирование объектной доменной модели, включающей бизнес логику и
взаимосвязи объектов
• Выделение локальной для отдельных объектов бизнес логики и логики поддержания
взаимосвязей из остального приложения
• Локальное хранение состояния сущностей вместе со связанным с ним поведением
• Повышение возможности повторного использования структуры данных и связанной
с ней логики
• Отделение от различных способов реализации – JPA, EJB2 сущности, DAO& DO
• EJB решает задачи синхронизации различных экземпляров одной по бизнесу
сущности между собой, обеспечивая ей поддержку жизненного цикла
• По мере усложнения сервисы, реализуемые бизнес объектами, становятся все более
разнообразными. Замусоривание лечится вынесением их в сервисы приложения
• Composite entity - использование сущностей - бинов для реализации модели домена
приложения
• Необходимость избежать использования удаленных бинов, связей с ними,
дополнительных запросов по сети
• Методы
• Использование BMP со специфической реализацией сохранения
• Адаптировать уже существующие POJO бины к сущностям
• Реализация стратегий безопасности и транзакционности – в построителе сложной
сущности
• Изоляция клиента от структуры хранилища данных, так как структура получаемых
клиентов бинов может не меняться синхронно со структурой базы
• Части шаблона – клиент (сессионный фасад или сервис уровня приложения),
составная сущности, входящие в его состав зависимые сущности (связанные в граф
сущности или POJO объекты)
• Родительский объект – независим, обладает собственным ЖЦ, независимо
развертывается и может повторно использоваться, выступает как фасад к зависимым
объектам
• Зависимый объект – имеет смысл только в контексте родительского объекта, тесно с
ним связан, сам по себе отдельно на клиенте существовать не может
• Transfer object, Value Object
• Необходимость эффективно передать набор данных через сеть
• Используется клиентом, которому надо читать или писать данные
• Необходимо минимизировать число запросов, идущих через сеть
• Необходимо повысить эффективность приложений, перегружающих сеть
большим количеством мелких запросов
• Повышение гранулярности запрашиваемых данных, использование при передаче
только значимых данных, уплощение структуры
• Части шаблона – клиент, компонент, передаваемый транспортный объект
• Клиент получает объект «только для чтения», чтобы отправить обратно изменения
формирует у себя новый объект
• Зачастую реализуется за счет наследования над серверной сущностью – типа отход
от дупликации кода, сомнительная практика
 • Снижение сложности за счет возможности решения задач синхронизации и контроля
версий
• Называются так, потому что структурированы на основе композитно включенных
объектов (значений), а не ссылок на объекты
• Представляют собой данные, сгруппированные вместе для поддержки одного или
нескольких сходных по функциональности прецедентов
• Жизненный цикл такого объекта полностью контролируется компонентом, не может
иметь собственного поведения
• Необходимо стремиться к минимизации объема данных. В идеале данные должны
точно соответствовать обслуживаемому прецеденту
• Transfer object assembler
• Формирование транспортного объекта за счет агрегации данных нескольких бизнес
компонент
• Сокрытие от клиента взаимосвязей бизнес объектов на сервере
• Минимизация сетевого трафика
• Упрощение модели данных для клиента до уровня, необходимого интерфейсу
• Автоматизация переупаковки данных между транспортными объектами и
объектами серверной модели данных
• Части шаблона – сборщик, бизнес объекты, DAO, сервисы и фасады сервисов,
транспортный объект
• Отделение бизнес логики от структуры представления данных, защита клиента от
изменения модели данных
• Экономия ресурсов клиента за счет выполнения преобразования данных на сервере
• Value list handler
• Альтернатива EJB-finder методам
• Удаленный клиент, который должен искать и итерироваться через большой набор
результатов
• Необходимость избежать использования большого числа Find – методов
• Способ избежать больших расходов на построение большого списка объектов
передачи данных
• Возможность использования транзакции «только для чтения» или работы в
не-транзакционном контексте
• Возможность хранить полученный набор результатов на серверной части
• Части шаблона – клиент, держатель списка результатов, фабрика доступа к данным,
список результатов, подсписок результатов, итератор по подсписку
• Кэширование результата поиска на сервере и выдача клиенту только необходимого
окна
• Реализация специфических стратегий поиска и кэширования результатов
• За счет кэширования – достижение транзакционной целостности результата поиска
• В свою очередь использует DAO для получения объектов и выполнения поиска
• Data access object
• Изоляция доступа к данным за счет выделения его в отдельный уровень
• Необходимость выделить и скрыть логику приложения при работе с хранилищем
данных
• Предоставление унифицированного доступа к данным вне зависимости от
механизма их хранения и доступа к ним
• Использование при доступе специфических для данных механизмов и сокрытие
их от остального приложения
• Фактически адаптер между компонентами приложения и источниками данных
• Обычно реализуется как бин без состояния, не кэширует результаты выполнения
запросов или что-либо, что клиент может получить сам отдельно потом. Поэтому
нет проблем с многопоточностью и конкурентным доступом
 • Части шаблона – клиент, фабрика доступа к данным, источник данных, набор
результатов, формируемый из данных транспортный объект
• Отделяет интерфейс ресурса от кода по его управлению
• Service activator
• Средство асинхронного вызова сервиса
• Возможность использования механизмов публикации / подписки и точка-точка
для поддержки асинхронного обмена сообщениями
• Разделение задач на полностью самостоятельные модули
• Части шаблона – клиент, запрос (реализует jms.Message), активатор сервиса
(реализует jms.MessageListener), сервис на основе POJO / EJB
• Domain store
• Возможность отделить логику сохранения данных, от объектной модели
приложения
• Возможность не завязывать объектную модель приложения на какой-либо
механизм или библиотеку хранения данных, не наследоваться, не реализовывать
интерфейсы и так далее
• Необходимость работать вне J2EE окружения, например в веб контейнере
• Необходимость использования в модели наследования и сложных взаимосвязей
• Части шаблона – менеджер хранения, фабрика менеджера хранения, менеджер
состояния, менеджер хранилища, интерфейс хранимости, которых реализуют бизнес
объекты, ресурс с данными
• Оптимизация логики выборки и сохранения графов объектов, отложенная
загрузка данных, кэширование наиболее часто используемых массивов данных
• Web service broker
• Предоставление доступа к набору уже имеющихся сервисов через XML / HTTP
• Повторное использование УЖЕ имеющихся сервисов различной природы с
унификацией интерфейса доступа
• Ограничение набора предоставляемых методов сервисов, изменение грануляции
сервисов и аргументов
• Контроль качества обслуживания, реализация общей политики безопасности
• Предоставление доступа в соответствии с открытыми стандартными при
выполнении межплатформенной интеграции
• Адаптация уже имеющихся сервисов под отличающиеся бизнес требования
• Координация транзакции между несколькими сервисами
• Части шаблона – клиент, входная точка, веб-брокер, бизнес сервис

Gof
• Общее
• Разделяются по области применения
• Для создания объектов – ABFPS
• Для структурирования взаимодействующих объектов – ABCDFFP
• Для распределения ответственности и структурирования взаимодействия –
CCIIMMOSSTV
• Элементы шаблона – consequence, intent
• На экзамене спрашивают названия-аналоги, а также пакеты и классы, которыми
можно проиллюстрировать шаблоны

Создание объектов
o Abstract factory (Kit)
 Предоставляет интерфейс для создания семейств связанных или зависящих
между собой объектов без указания конкретных классов
  Интерфейс реализуется группой фабрик, каждая из которых отвечает какому-
то набору условий. Клиент, в зависимости от условий, использует
конкретную фабрику, для получения набора классов, отвечающих
окружении.
 Части шаблона – интерфейс абстрактной фабрики, конкретные фабрики,
абстрактные классы, конкретные классы
 Плюсы
• Изолирует клиента от знания конкретных классов, с которым он имеет
дело
• Облегчает замену одного семейства объектов - другим
• Обеспечивает автоматическую согласованность создаваемых одной
фабрикой объектов между собой.
 Сценарии применения
• Система должна быть изолирована от того, как объекты создаются,
собираются и представляются
• Система должна быть сконфигурирована на основе какого-то
семейства объектов из перечня возможных
• необходимо предоставить пользователю библиотеку классов,
изолировав его от излишних подробностей реализации и обеспечив
будущую гибкость.
 Примеры применения – DAO, Transfer Object Assembler
 Проблема с добавлением новых продуктов – требуется изменение
интерфейса, а затем и всех реализаций. Но зато легко создать новое
семейство уже известных продуктов
 Удобно для тестирования – достаточно проверить, что хотя бы один продукт
относится к требуемому семейству
o Builder
 Разделение процессов построения самого сложного объекта, от процесса
построения его частей. При этом один процесс построения может строить
объекты разных типов с разным содержанием
 Отделение кода строящего структуру объекта, от кода, строящего
содержания объекта. Как объект будет размещать полученное от клиента
содержание зависит от менеджера построения объекта. Данная информация
для клиента закрыта, ровно как и информация о внутренней структуре того,
что он получил
 Плюсы
• Позволяет незаметно для клиента варьировать внутреннюю структуру
формируемых объектов.
• Обеспечивает гибкость процесса формирования структуры
• Изолирует код, отвечающий за формирование объекта
 Сценарии применения
• Алгоритм конструирования объекта очень сложен, не хочется его
раскрывать, возможно, он изменится со временем
• В зависимости от входных условий внутренняя структура
создаваемого объекта меняется
 Отличие от абстрактной фабрики – там клиент требует совместимый с
условиями объект, а здесь объект с некоторым предлагаемым клиентом
содержанием. Внутренняя структура самого объекта может быть неизвестной
клиенту и меняться на ходу
 Части шаблона – абстрактный построитель, его реализация (конкретный
алгоритм), менеджер построения объекта, вызывающий пошагово
построитель для получения финального объекта
o Factory Method (Virtual Constructor)
 Делегирование логики создания конкретных продуктов методу наследников
абстрактной фабрики. То есть для каждого конкретного продукта –
наследуем конкретную фабрику
 Плюсы
• Изоляция приложения от зависимостей от конкретных классов
• Большая гибкость при создании экземпляра класса
 Сценарии применения
• Клиент не знает, какой именно класс он хочет получить
• Класс хочет, чтобы его субклассы определили что за объекты будут
создаваться и как именно это будет происходить
 Примеры применения
• J2EE - EJBHome, EJBLocalHome, QueueConnectionFactory,
TopicConnectionFactory
• JSE – Collator, ContentHandlerFactory, InitialContextFactory,
SocketFactory
 Части шаблона – абстрактный продукт, абстрактная фабрика с методом,
возвращающим абстрактный продукт, конкретная фабрика, с методом
возвращающим конкретный продукт
 Наследники фабрики могут использовать базовую функциональность для
«доработки» созданного родителем объекта.
• Prototype
o Создание нового объекта по требованию клиента методом
клонирования уже существующего
o Плюсы
 Необходимо на ходу перестраивать перечни объектов, которые
могут быть созданы
 Стоимость создания и конфигурирования объекта стандартным
образом слишком высока. Сюда же идут пулы повторно используемых
объектов.
 Какой именно объект нужен выясняется динамически
(например, в случае динамической загрузки классов), а связываться с
фабриками не хочется
 Объект может быть только в одном из ограниченного набора
состояний. Если объект «read only», то можно заранее создать все
возможные его экземпляры и обеспечить их возможное использование
o Сценарии применения
 Какие классы на самом деле нужны и с каким наполнением
выясняется только в процессе работы приложения
 Хочется избежать построения иерархии фабрик, параллельной
иерархии конструируемых объектов. Делегирование вместо
наследования
 Конструируемые объекты могут находиться только в одном из
нескольких состояний
o Клонирование вместо создания может сильно уменьшить число
объектов в системе
 Если редактирования не предполагается – все раздаем один и
тот же
 Если клиент изменяет – создаем новый объект, для этого нужен
прокси «copy on write»
o Проблема в сложности реализации clone процедуры, особенно когда
структура объекта сложная и возможны зацикливания между частями
• Singleton
o Обеспечение наличия с системе только одного экземпляра некоторого
объекта
o предоставление глобальной точки доступа к нему
o Представляет собой замену глобальным переменным и упрощает
использование пространства имен
o Пример - Runtime

Структурные шаблоны
• Adapter (Wrapper)
• Преобразование интерфейса класса в другой интерфейс, который ожидает
пользователь. Также содержит всю логику по преобразованию данных между
двумя моделями, своей и чужой, причем преобразования выполняются в обе
стороны
• Плюсы
• Позволяет взаимодействовать двум классам, которые для этого не
предназначены
• Облегчает повторное использование существующей
функциональности, в том числе адаптацию одного компонента под
различных клиентов и окружения
• скрывает от пользователя подробности реализации адаптируемого
объекта, уменьшая связность и позволяя им развиваться независимо.
• Примеры – JCA, ajava.awt.event.ComponentAdapter
• Адаптер объекта
• необходимый интерфейс, адаптер который его реализует и содержит
ссылку на экземпляр «чужого» класса
• подходит и к наследникам класса, с точностью «до»
• сложнее переопределять поведение адаптируемого класса, так как нет
доступа к его потрохам
• Адаптер класса
• интерфейс, адаптер который его реализует и наследуется от
экземпляра «чужого класса».
• Недостаток – наследники класса таким образом оказываются
«неадаптированными»
• Достоинство – легче реализуется, так как знает больше о
адаптируемом классе
• Для тестирования адаптера хорошей практикой является создание эталонного
экземпляра «чужого» класса, эмулирующего преобразуемое поведение
• Bridge (Handle / Body)
o Отделяет абстракцию от реализаций поведения, позволяя каждой развиваться
независимо. Облегчает расширяемость системы
o для реализации различных вариантов единой абстракции используется не
наследование, постоянно связывающее реализацию с поведением, а включение,
позволяющее менять поведение на ходу
o позволяет строить независимые иерархии абстракций и реализаций
o Сценарии применения
 Необходимость избежать постоянного связывания между двумя
функциональными абстракциями
 Необходимость развивать и абстракцию и поведение путем наследования,
но независимо друг от друга
 необходимость менять реализацию поведения на ходу, возможно даже не
перекомпилируя систему
o Части шаблона – абстрактная сущность, содержащая абстрактное поведение,
конкретные реализации сущности, которые используют различные конкретные
реализации поведения
o Реализации могут быть протестированы сами по себе, для тестирования
абстракций требуется заглушки, реализующие тестируемое поведение
o Рекомендуется реализовывать мост в виде фабрики объектов, тогда и абстракции
и реализации будут согласованы и закрыты от пользователя
o Проблемы с производительностью
o Если экземпляры абстракции сильно отличаются друг от друга, то реализации
будут представлять собой произведение всех необходимых методов, что сделает
их интерфейс слишком широким
• Composite
o Представление часть-целое отношений в виде древовидной структуры
o Плюсы
 Определяет иерархию одинаково над примитивными и сложными объектами.
 Облегчает добавление новых типов компонент. для этого не надо изменять
уже имеющийся код и клиентов тоже
 Обеспечивает гибкость структуры минимальным интерфейсом
o Части шаблона – компонент, его реализации – лист и ветка (коллекция
компонент). Операции, определяемые компонентом, ветки реализуют как
итерацию над дочерними компонентами и вызов соответствующих операций
o Скрывает от клиента разницу, выполняется ли запрошенная операция над
объектом или агрегатом объектов
o Структуры может быть любой степени сложности
o Пример применения – Composite View из каталога J2EE шаблонов
o Проблема - трудно типизировано ограничить вкладывание компонентов друг
в друга, так как с точки зрения друг друга они все одного и того же типа.
Подклассы не учитываются на этапе компиляции, приходится выполнять
проверки во время выполнения программы
• Decorator (Wrapper)
o Добавление дополнительных ответственностей к объекту динамически в
процессе выполнения и прозрачно для пользователя, альтернатива наследованию
o Принимает исходный объект как параметр, реализуя его интерфейс, но
подмешивая новую функциональность
o Плюсы
 Большая гибкость, чем при статическом наследовании
 Нет необходимости размещать более богатые функциональность классы на
вершине иерархии
 Позволяет легко разделить сложное поведение на несколько функционально
связанных классов, вместо того, чтобы смешивать все в один объект
 Большая гибкость при расширении функциональности уже готовых классов –
можно дописывать дополнительные объекты. Но – нет доступа к их
внутренней части. Из-за этого может потребоваться нарушение инкапсуляции
o Может быть набраны любые варианты, последовательно видоизменяющие
исходное поведение. Пример – потоковые операции.
o Сценарии применения
 Необходимость на ходу видоизменять поведение, добавляя кросс
функциональность
 Когда одно и то же поведение может быть реализовано с различными
опциями и пользователю может понадобиться любая их комбинация. В такой
ситуации наследование критически увеличит количество конечных классов
  когда наследоваться от класса нельзя: не известно от какого именно или он не
расширяем. Или к примеру этот класс будет меняться в будущем и потом
доступен только в качестве интерфейса
o Части шаблона – абстракция, декоратор, реализующий абстракцию,
принимающий в качестве параметра абстракцию - ребенок, конкретные
декораторы, вызывающие после и перед вызовом метода ребенка свои
фрагменты кода
o Примеры – EJBObject, BufferedReader, IO, awt
o Проблема
 в системах, основанных на данном шаблоне, нельзя полагаться на
идентификацию и типизацию объекта, который используется. Никогда нельзя
знать, чем и кем он был обернут.
 Много мелких передач управления, теряется производительность сложно
отлаживать.
• Façade
o Предоставление унифицированного интерфейса, к набору подсистем,
располагающихся за ним. Уменьшение связности клиента с подсистемами и
подсистем между собой
o Плюсы
 Минимизация зависимости клиента от конкретных подсистем, их связей
между собой, внутренних моделей данных и логики их обработки
различными подсистемами
 Улучшение предоставляемого клиенту API, повышение гранулярности,
реализация общесистемных политик контроля доступа и минимизации
ресурсов
 Снижение сетевого трафика и количества запросов
 Вместо запроса систем друг к другу – запросы к фасаду, уменьшается
сложность, ликвидируются циклические зависимости. Последнее особенно
удобно для выстраивания процесса компиляции больших систем
 Упрощается развитие системы и перевод на другую платформу, потому
что можно подсистемы мигрировать по частям
o Сценарии примения
 Предоставление клиенту упрощенного интерфейса к сложной системе
 Снижение зависимости клиента от архитектуры лежащих за фасадом
подсистем
 Разделение системы на сравнительно независимые друг от друга слои,
локализация зависимостей в фасадных интерфейсах
o Пример – java.net.URL
• Flyweight
• Эффективное использование большого числа мелких объектов в условиях
недостатка памяти или высоких накладных расходов на передачу объектов, их
поиск и так далее.
• Минимум состояния оставляется объектам - внутренне, максимум
используется ими совместно или передается их операциям в виде контекста /
параметров - внешнее.
• внешнее состояние может не храниться, а вычисляться исходя из внутреннего
состояния
• Плюсы
• Снижает число объектов, с которыми приходится иметь дело
• Снижает требования к памяти, занимаемой этими объектами
• Шаблон применяется, если все нижеперечисленные условия выполняются
 • Приложение использует большое количество объектов в условиях
высокой стоимости хранения
• Большая часть данных, используемая объектами, может быть вынесена
вовне их и использоваться ими совместно
• За счет вынесения большое количество объектов может быть заменено
всего несколькими
• Приложение не завязано не идентичность данных объектов, то есть оно
их не различает
• Часто применяется вместе с композитом. При этом объекты хранят ссылку
только на детей, а ссылка на родителя передается им как контекст при
выполнении операции
• Пример - String
• Proxy (Surrogate)
• «Заместитель» или суррогат объекта, пробрасывающий вызовы к реальному
объекту вместе с необходимой пред и пост обработкой и осуществлением
контроля над вызываемыми операциями
• Используется в ситуациях, когда необходима более интеллектуальная ссылка не
объект, чем простой указатель
• Разновидности:
• Удаленный – скрывает реальное расположение объекта, позволяет его
вынести в другое адресное пространство
• контроль безопасности - может скрывать от пользователя класс, который
недопустимо ему показывать по тем или иным причинам. Может
контролировать права доступа
• управление ресурсами - загрузка по требованию ,подсчет числа ссылок, пул
объектов, загрузка из хранилища, «copy on write» и т.д.)
• реализация концепции AOP
• Части шаблона – интерфейс объекта, прокси и сам объект, реализующие
интерфейс. Прокси хранит ссылку на объект и пробрасывает вызовы методов
интерфейса
• Пример: EJBObject, все, в чем есть фрагмент названия «stub»

Поведенческие шаблоны
o Chain of responsibility
 Процесс получения результата должен распадаться на произвольно
комбинируемые части, допускающие легкую реконфигурацию логики в целом.
Число и состав этапов обработки заранее не известны
 Клиент понятия не имеет, кто именно в результате обработает его запрос, это
выясняется динамически по мере передачи запроса по цепочке обработки
 Плюсы
• Уменьшение связывания отправителя и получателя путем внедрения
между ними произвольного числа промежуточных обработчиков
• Увеличение гибкости, за счет разделения отдельных ответственностей
по отдельным обработчикам
• Позволяет многим обработчикам работать как единое целое
 Сценарии
• Множество потенциальных обработчиков запроса, кто именно
обработает – отправитель не знает и заранее не известно
• Множество динамически перестраиваемо, в том числе на ходу
 Примеры - RequestDispatcher
  Части шаблона – клиент, абстрактный элемент цепочки, который определяет
операцию обработки и коллекцию ссылок на детей, конкретные элементы,
реализующие конкретные операции обработки сообщения
• Command (Action, Transaction)
• Представление запроса клиента в виде объекта с параметрами. Таким образом,
клиент лишается возможности сформировать невыполнимый запрос
• Отделяет объект, запрашивающий операцию, от объекта реально выполняющего
операцию
• Жизненный цикл команды может быть существенно сложнее, чем просто
выполнение запроса. Команда вообще может быть выполнена в независимом
адресном пространстве с произвольно сложной пред и пост обработкой
• Используется для логирования, выстраивания в очередь, сохранения при
перезагрузки системы, маршрутизации между сервисами, выполнения undo
операций, реализации транзакций
• Объектно-ориентированная замена callback функциям, широко используется для
разделения приложения на ядровой код (активатор) и плагины (команды).
• Могут вкладываться друг в друга для представления высокоуровневых операций в
виде композиции низкоуровневых, шаблон – композит.
• Легко вводить в приложение новые команды, в том числе
• новую логику за счет наследования команд друг от друга
• формирования сложных команд, использующих более простые.
При этом код уже существующих команд не меняется
• Части шаблона – клиент, абстракция команды, конкретная команда, настроенная на
адресата, адресат, метод которого дергается конкретной командой, активатор,
который собирает у себя коллекцию команд и запускает их сообразно с какой-то
логикой.
• Примеры – Servlet по отношению к HttpServletRequest
• Interpreter
• Представление языковой конструкции в виде набора объектов, объединенных в
дерево выражения
• Необходимы условия: грамматика должна быть простой, а требования к
производительности не слишком строгие. В противном случае надо использовать
другие инструменты
• Части шаблона - контекст, абстрактное выражение, две его реализации:
терминальное выражение и нетерминальное выражение, содержащее коллекцию
абстрактных выражений. Для абстрактного выражения определена функция
«интерпретировать», принимающая в качестве параметра контекст
• Классы интерпретатора реализуют грамматические конструкции, соответственно
легко добавлять новые через наследование или комбинацию
• Добавление новой реализации поведения грамматической конструкции через
шаблон «визитор»
• Плюсы
• грамматику легко изменять и расширять
• реализация грамматики тривиальна
• Iterator
• Последовательный доступ к элементам агрегата без необходимости раскрытия
подробностей его внутренней реализации
• Дополнительные возможности:
• Поддерживаются различные способы итерации
• Много клиентов, одновременно итерирующихся по агрегату
• Независимость логики итерации от реализации агрегата
 • Итератор сильно упрощает интерфейс агрегата. Совершенно различные по
природе агрегаты могут использовать один и тот же итератор
• Части шаблона – интерфейс агрегата с функцией, создающей и возвращающей
клиенту абстрактный итератор, абстрактный итератор, конкретный агрегат,
конкретный итератор, в котором локализуется логика итерации, а также хранится
состояние процесса для конкретного клиента
• Примеры – Enumeration, Iterator, ValueListHandler, пакет java.util
• Mediator
• Вынесения логики взаимодействия множества объектов в отдельный объект. Вместо
взаимодействия «все со всеми» - «все с одним и один со всеми»
• Локализация и изоляция зависимостей между объектами и логики их
взаимодействия. Проще поддерживать и изменять логику взаимодействия.
• Выполнение централизованных и кросс операций, типа логирования или
безопасности, возможность централизованного контроля над трафиком
• Система становится менее монолитной, модульная реализация
• части становятся более простыми и заменяемыми, так как должны поддерживать
взаимодействие не со всеми другими частями, а только с центром
• Части шаблона – объекты системы, центральный медиатор, объектные медиаторы,
служащие объектам для доступа к центральному. В роли объектных медиаторов
может выступать стандартный интерфейс объектов, при помощи которых они
регистрируются в медиаторе
• Упрощается протокол взаимодействия, упрощается его изменение за счет
концентрации всей логики в одном месте
• Пример – интеграция множества компонент через систему обмена сообщениями
• Memento (Token)
• Реализация возможности сохранения / восстановления состояния объекта без
необходимости раскрытия подробностей его внутренней организации. Представляет
собой черный ящик со снимком внутреннего состояния объекта
• Части шаблона – объект с внутренним состояние и функциями создания снимка и
загрузки снимка, снимок с внутренним состоянием, клиент, хранящий у себя набор
снимков объекта
• В основном используется для работы с checkpoint / undo
• Упрощается реализация клиента в части сохранения состояния в различных формах,
всю эту логику можно убрать в снимок
• Недостаток в том, что клиент не может управлять тем, какую часть состояния он
получит, может в частности получить слишком большой объем данных, в общем
«кот в мешке». Особенно это неприемлемо, если операции по работе со снимком
выполняются часто, а реально меняется только небольшая часть данных
• Пример – Bean-Managed Persistence
• Observer (Depends, Publish-Subscribe)
• В случае «один ко многим» зависимости между объектами предоставляет
возможность получения многими информации об изменении одного
• Применяется в ситуации, когда не известно заранее число, типы зависимых
объектов, а также ситуация, в которой им может понадобиться получение
уведомления
• Уменьшение связности между объектами до интерфейса наблюдателя и формата
сообщения
• Части шаблона – интерфейс публикатора с функциями управления списком
слушателей, сообщение, интерфейс слушателя с функцией получения сообщения
• Часто используется для разделения системы на слои и обеспечения взаимодействия
между слоями
• Средство многоадресной рассылки сообщений
 • Проблема – распространение информации становится недетерминированным, так
как не известно что подожжет уведомленный компонент. Могут возникать
каскадные эффекты и зацикливания. Трудно отлаживать
• Пример – Observer / Observable классы, вся технология JMS
• State (Objects for States)
• Предоставление объекту возможности менять поведение в зависимости от состояния
за счет выделение состояния и логики обработки запросов в нем в отдельную
сущность.
• Объект наделяется состоянием при создании и может динамически менять его в
процессе работы
• Состояние варьируется от перечисления, до сложного объекта, инкапсулирующую
часть логики обработки запроса
• Разделение поведения для различных состояний по отдельным объектам – замена
глобальным статусам и операциям ветвления от них
• Делает процедуру смена состояния явной и упрощает понимание, в каком из
состояний объект находится
• Защищает состояние объекта от несогласованности, когда разные его части
отвечают разным состояниям, облегчается отладка
• Одно состояние может разделяться между разными объектами, переход к
легковесному объекту.
• Strategy (Policy)
• Предоставление возможности модификации изменения базового алгоритма за счет
использования подключаемых модулей, варьирующих часть логики. Замещение
вместо наследования
• Используется когда
• Много различных классов или алгоритмов различаются только в деталях
поведения
• Необходимо изолировать клиента от подробностей алгоритма и используемых
им данных. Например, от настроек единого алгоритма
• Используется для поддержки семейства алгоритмов, когда они все слегка
отличаются друг от друга. Альтернатива наследованию, которое в данной ситуации
приводит к большому числу классов
• Каждый вариант поведения представлен собственным классом, что позволяет
избежать множественного ветвления внутри и упростить код реализации
• Позволяет менять поведение на ходу, причем согласованно, если поведение
определяется множеством параметров
• Возможность использования различных реализаций одного и того же поведения,
клиент выбирает в зависимости от своих потребностей
• Проблема – слишком большая гибкость, клиент должен понимать разницу между
различными стратегиями, сильное зацепление с реализацией
• Недостаток в слишком большой взаимосвязи между объектом и стратегией, они
слишком много должны знать друг о друге. Ситуация улучшается, если стратегия не
имеет состояния, а представляет собой чистый алгоритм
• Template method
• Описание скелета алгоритма в базовом классе за счет использования абстрактных
операций, которые реализуются в классах – наследниках
• Позволяет защитить базовую логику от изменения, обеспечив некоторую гибкость.
Гранулярность гибкости обуславливается числом и «размером» абстрактных
операций
• Хороший способ рефакторинга для вынесения основного повторяющегося кода в
базовый класс
• Способ определения слушателей, перехватывающих точки в базовом алгоритме
 • Пример – HttpServlet относительно просто Servlet
• Visitor
• Определение множества операций над графом объектов, возможность его изменения
без модификации классов объектов графа
• Способ изоляции алгоритмов обработки от структуры обрабатываемых данных.
• Части шаблона – интерфейс элемента структуры с методом применения визитера,
интерфейс визитера с методами обработки по одному на тип конкретного элемента
структуры, конкретные визитеры, каждый из которых реализует одну операцию
обработки данных
• Визитер собирает в одном месте все действия над всеми типами объектов,
необходимые для выполнения операции. Отделяя их собственно от структуры
объекта и логики итерации.
• Набор классов, входящих в граф, должен изменяться редко, в противном случае
будут высоки расходы на переписывание интерфейса визитера и всех его
реализаций. Добавление нового класса = добавление нового метода в интерфейс и в
каждый конкретный визитер
• Визитер переносит в себе состояние системы в целом, передавая его в качестве
контекста в операции конкретных элементов структуры. Другой вариант –
выделение в глобальный контекст
• Провоцирует реализовывать в объектах много методов, раскрывающих их состояние
с точки зрения визитера. Нарушение инкапсуляции

Безопасность
общее
• Терминология
• identity management - обеспечение единого контекста безопасности через всю
систему или взаимодействующие системы
• entity – что-то, к чему контролируется доступ
• principal – что-то, чему могут быть присвоены привилегии и роли
• protection domain – множество сущностей, находящихся под управлением одной
политики безопасности и доверяющие друг другу
• authorization - применение политики безопасности к паре сущность / принципал,
ограничивает возможность доступа к конкретной сущности и тип доступа
• JEE обеспечивает
• единый домен безопасности от веб приложения, до EIS системы.
• Граница защиты – по веб приложению, далее информация распространяется
(propagate) по всем контейнерам и посредством SSO между отдельными серверами
• Не требуется поддержка контейнером нескольких доменов безопасности, хотя
может и предоставляться
• Декларативную политику безопасности для приложения устанавливает deployer во
время развертывания
• Обеспечивается интероперабельная и платформенно независимая инфраструктура
безопасности, интегрированная с базовой операционной системой и развернутыми на ее
основе сервисами
• Мандат пользователя (user credentials, security token) – надежные данные о пользователе,
полученные на основе процесса аутентификации. Может быть в разных формах (логин /
пароль, X.509 сертификат, Kerberos ticket, SAML token).
• Атаки: для парольной пары – перебор, для сертификата – ошибки при
распределении сертификатов, проблемы при отзыве
• Стандарты
 • SAML – XML протокол обмена утверждениями в области безопасности для
поддержки SSO и общего logout. Liberty его использует и расширяет
• XACML – язык для описания ACL и управления политиками безопасности,
• позволяют различным вендорам в области безопасности интегрироваться друг с
другом. Особенно важно, когда одновременно используется одновременная работа с
несколькими версиями одного ПО

Обзор потенциальных угроз

• Сбойные данные пользователя (input validation failure)
• Проверка введенных пользователем данных перед запуском процесса обработки
критична для безопасности системы. Также желательно
• проверять данные потребляемых доверенных и не доверенных ресурсов.
• Повторно проверять введенные данные на сервере перед обработкой
• Типовые проверки – тип данных, формат, длинна, диапазон значений, null
допустимость, кодировка, локаль, соответствие шаблону, соответствие бизнес
контексту, перечень разрешенных значений
• Типовая угроза – выполнение клиентом опасного скриптового кода
• Очистка вывода. (output sanitation)
• Предотвращение атаки за счет вывода введенных пользователем данных. Особенно
часто встречается в веб приложениях.
• Переполнение буфера. (buffer overflow)
• Обычно используется для DOS атак или внедрения разрушающего кода.
• Предотвращается контролем вводимых пользователем данных, очисткой вывода и
удалением исполнимых инструкций из введенных пользователем данных
• Введение исполнимых инструкций под видом данных. (data injection flaw)
• Наиболее часто встречается в веб приложениях в виде JavaScript кода, а также в
форме внедрения SQL, когда данные непосредственно подставляются в SQL запрос.
• Межсайтовый скриптинг (Cross-site-scripting, XSS)
• Атака за счет внедрения на страницу пользователя ссылки активизируемой
пользователем или автоматически запускаемого скрипта с другого сайта,
производящего разрушительные действия
• Наиболее часто – выполнение действий от лица пользователя в системе, воровство
аккаутна, воровство куков или сессионной информации
• Неправильная обработка ошибок (improper error handler)
• выброс пользователю сообщений об ошибке, содержащих системную информацию,
которая может быть использована для взлома
• Альтернатива – пользователю выводим сообщение в бизнес терминах и ИД
проблемы, по которой в логу можно отыскать всю необходимую информацию
• Незащищенное хранение или передача данных (insecure data transit or storage)
• Для защиты конфиденциальности и целостности данных во время передаче может
применяться шифрование и подпись
• Слабый ИД сессии (weak session identifier)
• Использование перехваченного ИД сессии позволяет использовать ее атрибуты и
осуществить атаку от имени пользователя
• Защита
• использование пользовательской сессии только после установления
защищенного SSL соединения
• подтверждение идентификатора сессии, полученного от клиента, при помощи
криптографических средств
• обязательный сброс сессии после истечении срока ее годности
• слабый токен безопасности (weak security token)
 • позволяет пользователю атаковать пароль токена за счет перебора (просто или по
словарю) и осуществить атаку от имени другого пользователя
• проблема в том, что в веб приложениях пароль / токен всегда передаются в
открытом виде по сети и могут быть получены хакером для изучения
• решение – использование сертификатов, биометрических средств, смарткарт
• Слабость пароля (weak password exploits)
• Пароль – слабейший из механизмов, применяемых для аутентификации, легко
может быть перехвачен или подвергнут процедуре подбора
• Также атаке подвержены базы с паролями – лучше не хранить пароли в открытом
виде, допускающем использование. А только в свернутом, не допускающем
восстановление в исходном виде
• Слабое шифрование (weak encryption)
• Кража сессии (Session Theft)
• Способ атаки за счет использования чужой сессии или создания новой при клиент-
серверной и сервер-серверной атаке
• Способ – кража, удвоение или подбор ИД сессии, анализ куков в которых он
хранится
• Борьба – очистка сессии после logout, шифрование сессионной информации, работа
через защищенный канал SSL/TLS
• Незащищенные конфигурационные данные (insecure configuration data)
• Ошибка в конфигурировании SSL сертификатов и настройки криптографии
• Использование дефолтных сертификатов, аккаунтов, паролей
• Ошибка конфигурирование плагинов веб сервера
• Ошибка в аутентификации (Broken Authentication)
• Причины – проблемы с конфигурированием механизма, процедура восстановления
забытого пароля, смены пароля или сертификата
• Защита – повторная проверка данных пользователем при выдаче прав
плользователю
• Ошибка в контроле доступа (Broken access control)
• Приводит к потере конфиденциальных данных и выполнению от имени
пользователя недопустимых операций
• Решение – периодическое тестирование перечня контролируемых ресурсов на
различные типы доступа
• Ошибочная политика безопасности (Policy Failures)
• неполный / неверный перечень возможных угроз, на отражение которых рассчитана
система
• проблема проектирования
• выполнение логирования и аудита (audit and logging failures)
• средство своевременного выявления потенциально опасной активности или следов
уже удавшегося взлома
• логи сами по себе должны защищаться, так как их информация может служить для
проведения атаки
• отказ в обслуживании (DOS and DDOS)
• атака на сетевом уровне, приводит чрезмерному потреблению или отказе в доступе к
ресурсу
• особенно подвержены веб приложению в силу принципиальной невозможности
отличить правильный запрос от спама
• средства защиты – фильтрация по IP и имени хоста, отказ в обслуживании
диапазонов и сетей, разброс запросов по множеству обработчиков
• шаблоны – secure pipe, intercepting web agent, intercepting validator
• внедрение посредника (man-in-the-middle)
 • хакер как прокси между клиентом и сервером, особенно подвержены веб системы и
системы обмена сообщениями
• внедрение в бизнес транзакцию за счет прослушивания, подмены идентификатора
сессии, слабостей в криптографии и т.д.
• метод борьбы – защита на транспортном уровне за счет SSL/TLS, IPSEC, шаблон
Secure Pipe
• Множественная аутентификация (Multiple Sign-on)
• Атака за счет использования данных устаревших сессий, потери на повторные
операции, человеческие ошибки и их обработка, частое обращение к ресурсам при
отсутствии на них прав
• При взаимодействии между самим приложениями – защита на уровне слабейшего
звена
• Решение – SSO
• Проблемы с развертыванием и кодированием
• Необходимость периодического review код на недопущение перечисленных выше
проблем

Составные аспекты безопасности

• Метафора «колеса со спицами» - каждый компонент системы, располагающейся в
центре, должен быть «прикрыт» всеми аспектами для обеспечения целостности всей
конструкции:
• Операционная система, должна быть минимизирована ото всех ненужных
компонент, протоколов, прикладного ПО, а также сконфигурирована в режиме
максимальной безопасности (hardened), предусмотренном вендором
• Identity Management - репозиторий данных для работы с пользователями, группами,
ролями, привилегиями и т.д.
• Отдельные функциональные модули (спицы колеса)
• Аутентификация
• Авторизация
• Конфиденциальность данных при хранении и передаче
• Целостность данных, защита от их несанкционированного изменения или
подмены в процессе передачи
• Поддержка политик доступа на основе правил
• Аудит действий приложений / системы, необходимо для обнаружения атак, а
также при судебных разборках
• Механизм централизованного управления всеми механизмами, относящимися к
безопасности
• Обеспечение доступности приложения в случае возникновения проблем и отказа
сервисов
• Обеспечение целостности приложения с точки зрения стандартов и
предъявленных требований
• Ведение системных логов, в отличии от бизнес логов формирование записей не
носит транзакционного характера
• Инфраструктура открытых ключей, в частности управление ключами
• Поддержка меток доступа процессов / обрабатываемой информации
• Периметр безопасности – сетевые компоненты, такие как роутеры, файрволы,
фильтры пакетов, детекторы проникновения и т.д., обычно между приложением и
интернет
• Каждый компонент в системе должен быть исследован на предмет возможных рисков и
компромиссов с точки зрения выполнения остальных функциональных и
нефункциональных требований
Проектирование и разработка
• Аспект безопасности должен быть с самого начала дизайна и разработки приложения.
Зачастую относится на конец разработки (RUP construction) или даже на начало пред
продуктового тестирования, когда
• возможности по его внедрению крайне ограничены и многие дыры уже прикрыть не
получится
• реализация приводит к возникновению проблем с производительностью, а также с
юзабилити.
• У RUP-a проблемы с достижением не функциональных требований к системе, они их
наличие подразумевается, но не учитываются как часть процесса. В полной мере
относится к безопасности.
• Работу с безопасностью, в частности анализ требований и реализацию прецедентов,
можно так же разделить на фазы, но это другие фазы, нежели разработка прикладного
функционала. Потому как между прикладным разработчиком и разработчиком
безопасности всегда будет некоторый зазор
• Активности
• Анализ требований и формирование прецедентов- аналитик
• Требования производятся из бизнес требований с учетом индустриальных
стандартов, корпоративной политики, общих подходов
• Результат
• перечень требований по безопасности с трекингом относительно бизнес
требований
• перечень прецедентов с трекингом бизнес требований и требований
безопасности
• Разработка архитектуры - архитектор
• Разработка концептуальной модели безопасности, базирующейся на
существенных для архитектуры вариантах использования
• идентификация и анализ уязвимостей – Risk Analysis (RA) – оценка угроз, их
влияния на систему, возможных последствий и способов противодействия
• asset valuation – определение стоимости действий по минимизации риска по
приемлемого уровня
• quantitative risk analysis - количественный анализ риска, анализ вероятности
осуществления и частоты встречаемости, оценка стоимости потерянной /
раскрытой информации и прочих убытков от успешного осуществления
риска
• qualitative risk analysis – качественный анализ риска, идентификация и
анализ путей минимизации рисков
• идентификация и анализ альтернатив – Trade-Off Analysis (TOA)
• выбор вариантов достижения безопасности в соответствии с их различной
способностью минимизировать выявленные риски и ценой реализации
• Таблица, по строкам – критерии безопасности, по столбцам – опции защиты.
В каждой ячейке два числа – степени защиты и важность критерия
• Разработка предварительной архитектуры на основе компонентной структуры
ПО и шаблонов. Далее этот прототип будет уточняться на всех фазах работы,
особенно на этапе дизайна, примеряющего архитектуру безопасности с другими
требованиями к системе
• Дизайн - дизайнер
• Проведение анализа влияния других факторов. Выявленные факторы влияют
на выбор и стратегию применения шаблонов. Выражают ограничения,
налагаемые на подсистему безопасности, со стороны окружения и специфики
приложения
 • Общие инфраструктурные – на каких платформах будет развертываться,
число и тип точек доступа к приложению, промежуточных обработчиков,
модель использования сервисов (централизованная, децентрализованная,
распределенная, точка-точка), требования к сетевой безопасности
• Веб слой – требования к механизму аутентификации, перечень
поддерживаемых клиентских платформ (особенно в части объема памяти,
сложности поддерживаемых криптографических алгоритмов, наличия
специфического API), стратегия распределения ключей, требования к
авторизации, в частности гранулярность доступа
• Бизнес слой – природа информации, обрабатываемой в бизнес транзакциях
разных типов
• Веб-сервисы – метод вызова (RPC, Doc-style, синхронный, асинхронный),
типы взаимодействия (перехватчики, фильтрация сообщений, агрегация
сообщений от нескольких провайдеров и т.д.)
• Identity management – стратегия идентификация, политика доступа (кто чего
может использовать), ограничения со стороны отраслевых / корпоративных
стандартов, закона, требования к SSO
• QOS – требования к качеству предоставляемых сервисов
• Анализ влияния на архитектуру распределения компонентов приложения
по уровням / слоям и способов их взаимодействия друг с другом. В результате
появляется распределение элементов безопасности по слоям, а также выбранные
шаблоны адаптируются к реальной архитектуре приложения
• идентификации и исследования угроз – анализ уязвимости базового железа,
ПО и его конфигурации, выявление дополнительных дыр в безопасности.
Позволяет адаптировать развертывание к требованиям безопасности, может
применяться как к разрабатываемым, так и к уже готовым системам.
• анализ компонентной модели доверия
• как один раз установленная идентификация запроса распространяется при
вызовах компонентов системы между собой, как они при этом друг от друга
зависят, где и как идентификация может повторно устанавливаться /
проверяться, какие дополнительные риски связаны с этими процессами
• в результате перечислены элементы инфраструктуры, бизнес приложения и
компоненты, компоненты безопасности. Служит базой для формирования
тестов для прецедентов, в которых они задействованы
• классификации информации по уровню конфиденциальности – то есть
разграничение данных по тому, насколько их раскрытие / утрата окажут
существенное влияние на бизнес
• степени
• не классифицированная (unclassified)– предназначена для публичного
доступа, раскрытие не страшно
• важная, но не классифицированная (sensitive, but unclassified - SBU) –
публичный доступ должен быть закрыт, но раскрытие не приводит к
возникновению проблем
• конфиденциальная - должна быть закрыта как внутри организации, так и
от внешнего доступа. Раскрытие приводит к существенным
неприятностям
• Secret – раскрытие ведет к серьезным проблемам, должна специально
защищаться
• Top Secret – раскрытие является угрозой для бизнеса в целом
• За установление степени ответственен владелец, если он не уверен, то
присваивается «конфиденциальная»
• Инфраструктура поддержки классификации данных и процессов по уровню
конфиденциальности – как правило trusted OS, например солярка.
 Разграничение затрагивает всех пользователей, файлы, директории,
процессы, сервисы и приложения
• Формирование общей политики безопасности – набор правил и общих
принципов относительно того, как приложения и компоненты системы
реализуют сервисы по защите своих ресурсов.
• Как осуществляется доступ к информации, какие при этом предусловия
должны быть выполнены, как устанавливается возможность / невозможность
доступа, для кого какие типы доступа возможны и т.д.
• Типы политик
• Политика идентификации – набор правил и условий по установлению и
проверке безопасности
• Политика контроля доступа по доступу к ресурсам и операциям по их
обработке
• Политика защиты данных при хранении и передаче
• Сетевая политика по развертыванию и сопровождению серверов, сетевой
инфраструктуры и прочих сервисов
• Правовая политика – корпоративная, отраслевая, законодательная
• Информационная политика – опциональная, относительно
информирования организации и менеджмента относительно
происходящего в системе
• Адаптация общей архитектуры безопасности к остальным функциональным и
нефункциональным требованиям
• Оценка созданной архитектуры, как правило, производится внешним экспертом /
консультантом
• создание дизайна безопасности, в частности
• организация разделения компонент, относящихся к безопасности и к бизнесу,
чтобы они могли разрабатываться раздельно и разными людьми
• анализ применимости общей архитектуры безопасности на уровне каждой из
компонент
• Реализация архитектуры
• Финальная проверка дизайна и политики безопасности на отсутствие пробелов –
reality check, заключается в самопроверки результата предыдущей работы на
основании перечня вопросов, допускающих ответ да/нет. Может применяться к
готовому приложению в ходе выполнения процедуры аудита безопасности.
• Политика
• Политики для веб и J2EE приложений документированы и покрывают в
числе прочего
• Минимизацию и зачистку ОС всех хостов
• Защита серверов приложений
• Защита бизнес логики и объектов данных
• Защита объектов окружения и инфраструктуры хранения данных
• Соответствуют организационным стандартам и процедурам
• Определяет процессы шифрования / дешифрования данных, выбора
алгоритмов, генерации, распределения, смены ключей / сертификатов,
выбора поставщиков ПО и т.д.
• Определяет процедуры усиления в случае обнаружения атак или под
атакой
• Имеется план развития бизнеса, предусматривающий развитие
инфраструктуры защиты приложения и сопутствующие риски
• Доводится до руководства организации и сотрудников. Политика не
должна быть предметом только тех, кто занимается ее разработкой
 • Имеется ли политика определения доступа к данным и функциям
приложения. Документированы ли роли и группы. Достаточно ли гибко
разделение, вплоть до использования ACL. Как контролируется и
проверяется выполнение данной политики
• Документированы ли разрешения / запреты на используемые сервисы и
протоколы, топология сети, включая ДМЗ и сетевые устройства
осуществления, как часто обновляется документация. Данная
документация – основной источник идентификации потенциальных
пробелов в безопасности
• Как поддерживается секретность данных, разделены ли они по уровням,
есть ли документированная политика
• Осведомлены ли пользователями о разделении данных и процедурах
обращении с секретными данными
• Есть ли политика аутентификации / авторизации. Запрещает ли она
распространение идентифицирующих данных, как это контролируется
• Есть документированная процедура изменения политики
• Доступ к данным осуществляется на уровне не больше необходимого, то
есть аутентификация / авторизация производится на уровне отдельной
бизнес транзакции, а не работы с базой вообще – весь сервер приложений
под одной четной базой БД. Особенно при работе с несколькими базами
• Администрирование
• Как администируются процессы аутентификации и авторизации
• Есть ли механизм защиты процедур, связанных с управлением ключами /
сертификатам, документирован ли он
• Разделены ли между сотрудниками ответственности разработки дизайна
безопасности и администрирования
• Осуществляется ли регулярная установка патчей безопасности на все
используемое ПО
• Как координируются между собой действия администраторов,
выполняемые на разделенных объектах системы, например в разных БД
• Как выявляется неавторизованный доступ, например попыток
множественного неуспешного логина, есть ли системы автоматического
обнаружения и предупреждения администраторов, как производится
управление логами и их анализ
• Производится ли мониторинг процессов с точки зрения безопасности,
позволяющей найти следы подготовки атаки
• Отражены ли в логах аудита жизненно важные данные
• Операции аутентификации и авторизации
• события связанные с изменение структуры групп / ролей
• время выполнения операции
• ИД-ы пользователей
• Другие данные и результаты транзакций связанных с безопасностью
• Защищены ли данные логов от несанкционированного доступа /
подмены / удаления.
• Качество сервиса (QOS)
• Имеется ли план восстановления ключевых компонентов осуществления
политики безопасности (intercepting web agent, secure message router
intermediary), подвергшихся успешной атаке
• проверяется ли и как регулярно целостность и работоспособность этих
ключевых компонент
• предусматривает ли план восстановления использования альтернативной
инфраструктуры поддержки безопаности
 • есть ли документированный список Java объектов, веб сервисов, XML
сообщений и прочих компонентов приложений для которых
идентифицированы угрозы с точки зрения безопасности
• есть ли план управления рисками и процедуры восстановления для
каждого из выявленных типов возможной атаки / пробела в безопасности
• Клиентское устройство
• Проверяется ли наличие на клиенте следов потенциально вредоносного
ПО
• Защищены для клиентские ключевые пары и сертификаты от
несанкционированного доступа
• Уровень представления
• Как реализована процедура аутентификации
• Веб слой
• Как переносится и защищается информация, идентифицирующая сессию
• Шифруются ли данные передаваемые в рамках сессии
• Где хранится и как защищается информация, используемая для
аутентификации пользователя
• Подписаны ли локальные JAR, используется ли обфускация для код
• Как производится аутентификация / авторизация.
• Используется ли дополнительное железо для поддержки шифрования
передаваемых данных? Оно дороже и менее гибко, но дешевле и менее
подвержено атакам
• Какие технология шифрования используются, насколько надежны и
распространены алгоритмы, нет ли ограничений со стороны законов на их
использование
• Как осуществляется управление ключами, основная проблема – проверка
того, что сертификат не был отозван
• Как защищаются закрытые ключ, основные возможности – файл на
пароле, token устройство, доступ к LDAP через защищенный канал
• Аутентифицируется ли индивидуальный пользователь или некоторая
роль, когда много пользователей идет под одним логином. Последнее
очень плохо для последующих разборок
• Защищены ля Java security конфигурационные файлы и файлы политик,
например через ОС ACL или за счет нахождения на read-only устройстве
• Содержится ли в лог файлах ИД-ы пользователей и метки времени. Не
содержится ли там пароли, ключи и прочая закрытая информация
• Защищены ли лог файлы от неавторизованного доступа, удаления или
подмены содержимого
• Защищены ли данные посредством XML схем, которые локальны,
неизменяемы и контролируют формат и объем данных
• Бизнес уровень
• Используется ли механизм аутентификации / авторизации для контроля
доступа к отдельным приложениям / модулям приложений / данных
приложений
• Должен ли пользователь повторно аутентифицироваться для каждого
типа доступа или при передаче вызова между приложениями.
Распределяется ли единый контекст безопасности через всю цепочку
обработки запроса
• Сбрасывается ли сессия работы на основании периода неактивности.
• Есть ли механизм запрета выполнения сетевых операций для
неавторизованной активности
 • Защищены ли операции авторизации / аутентификации при доступе к
базе, защищается ли JDBC протокол
• Подвергнуты ли транспортные объекты EJB обфускации
• Используется ли Супер-ИД сервера приложений для работы с базой, что
не позволяет отследить пользователя на уровне работы с данными.
Определять права при работе с ресурсами лучше на основе ролей, нежели
индивидуальных пользователей – более гибко и управляемо
• Имеется ли тесная связь между бизнес логикой и логикой безопасности
• Интеграционный уровень
• Передаются ли важные с точки зрения безопасности или
конфиденциальности данные в составе SOAP сообщений. Производится
ли защита таких сообщений или их частей с помощью XML шифрования /
подписи
• Деактивированы ли неиспользуемые сервисы ОС и сетевые устройства
• Проверяются ли содержимое SOAP сообщений и вложений на
подозрительные атакующие включения
• Могут ли промежуточные обработчики изменять содержимое SOAP
сообщений, как в этом случае контролируется их целостность и
подлинность
• Защищены ли используемые WSDL файлы. Любой доступ к ним должен
быть ограничен для идентифицированных пользователей. Должен быть
запрещен динамических вызов сервисов на основе исследования WSDL
• Используются ли ИД-ы пользователей при доступе к UDDI и прочим
реестрам. Обеспечена ли высокая доступность этих реестров
• Контролируется ли целостность цепочки SOAP сообщений, используются
ли метки времени при подписи – защита от потерянных сообщений и
внедрения сообщений
• Ограничены ли используемые токены временем жизни - защита сервисов
приложения от перегрузки запросами
• Все ли используемые ресурсы контролируются на основе прав доступа
• Выполняются ли регулярно тесты безопасности и сканирование на дыры
для всех серверов / сетевых устройств
• Разработчиком - реализация кода, формирование конфигурации, настройка
инфраструктуры, написание руководств по настройке сторонних средств,
настройка компонентов сетевого уровня, минимизация и hardening ОС,
внутреннее юнит тестирование
• Исследование готового кода дизайнером и выполнение системных тестов на то,
что заявленные функциональные и нефункциональные требования
удовлетворены. В том числе тестирование влияния на производительность,
соответствия QoS / SLA соглашений
• Тестирование
• В режиме белого ящика
• исследование кода, поиск и проверка уязвимостей, обнаружение большинства
дыр, специфичных именно для данного приложения
• Примеры – проверка входных параметров, конкурентные проблемы, утечка
ресурсов и т.д.
• В режиме черного ящика
• снаружи без использования знания о внутреннем устройстве, обнаружение
слабых мест системы в целом, а не специфичных для конкретного
приложения.
 • Данные проблемы не могут быть предусмотрены на предыдущих этапах
разработчиками или аналитиками, вскрываются только по результатам
тестового развертывания
• Проверяются уязвимости, наличие которых ожидается на основании перечня
объектов инфраструктуры и т.д. От неправильной конфигурация хоста (ОС,
патчи), сетевых устройств до проблем специфической версии виртуальной
машины
• Результат – протокол тестирования, перечень использованных средств, перечень
и результат тестов, перечень выявленных слабых мест и дыр
• Развертывание
• Установка окружения
• Общая схема развертывания окружения – железа, ПО, сетевой конфигурации
• набор SOP (Standart Operating Procedure) по развертыванию,
конфигурированию, обслуживании и разрешению проблем с базовым
железом и ПО
• политика осуществления работ по Change Management Request
• Установка патчей
• Руководство по использованию выбранного средства работы с патчами
• Политика проведения работ по установке патчей
• Восстановление после сбоев
• Архитектуры безопасности должна включать документированные процедуры
восстановления после сбоев / успешных атак а также поддержания
работоспособности системы в целом под атакой
• Мониторинг
• Внешняя периодическая активность для системы после развертывания в течении
всей эксплуатации. Средство достижения уровня сервиса, заданного SLA
• В том числен проверка своевременности наложения патчей, как системных так и
программных
• Аудит
• Внешняя периодическая активность для системы после развертывания в течении
всей эксплуатации. Средство достижения уровня сервиса, заданного SLA
• Проверка на соответствие системы стандартам, выполнение организационных
политик, проверку выполнения требований, конфигурации ПО, хостов, сети и
т.д.
• Исследование журнала событий пользовательской активности на предмет поиска
следов успешных и неуспешных атак

Архитектура безопасности J2SE

• Безопасная среда исполнения обеспечивается на пересечении архитектуры JVM и
средств языка разработки.
• Стандарт фиксирует размер примитивов и порядок выполнения операций
• Языковый контроль доступа на уровне переменных и методов
• Языковый запрет на определение и разыменование произвольных указателей -
нельзя создать и запустить произвольный код в некоторой области памяти
• Инкапсуляция на основе вызова кода по контракту – интерфейсы
• Строго типизированный язык, контроль на этапе загрузки байткода
• Возможность определить метод или класс в качестве финальных, запретив таким
образом изменение функциональности через наследование
• Системный сборщик мусора, не дающий возможность высвободить участок памяти
вручную
• Дополнительные возможности по защите Java кода
• Аутентификация загружаемого из недоверенного источника кода
 • Шифрование кода в процессе передачи или перед выполнением
• Обфускация
• переименования всех идентификаторов
• Трансформация данных, например из локальных в глобальные переменные,
изменение размерности массивов
• Изменение порядка выполнения инструкций приложения
• Шифрование всех литералов
• Вычисление отпечатка кода, идентифицирующего программу. Его проверка
или использование индивидуальности, чтобы идентифицировать хакера
• Использование специфики декомпиляторов для обрушения или
формирования неправильного исходного кода
• История
• Изначально, версия 1.0.х – вводится понятие песочницы (sandbox),
ограничивающей возможности исполнимого кода
• Все приложения, исключая аплеты, выполняемые локально имеют доступ ко
всем ресурсам JVM
• Все приложения, загруженные с других хостов, в частности апплеты,
выполняются ТОЛЬКО в песочнице. Ограничения не настраиваемые
• Начиная с версии 1.1.х появляется концепция подписанных апплетов, которые
поставляются вместе с доверенными публичными ключами поставщиков и
выполняются также в режиме полного доступа к ресурсам JVM
• Начиная с версии 2 модель существенно усложняется.
• Теперь весь код, независимо от источника его загрузки, исполняется в рамках
одной из сконфигурированных политик безопасности, определенной для
определенного домена (эквивалент песочницы.)
• Поставщики криптографических сервисов для управление подписями,
публичными ключами
• Основанная на правилах загрузка классов и проверка байткода
• Подпись кода и уровни совместимости
• Модель безопасности - встроенная, управляемая политиками, на основе доменов
безопасности
• Домен защиты (ProtectionDomain) – связывает между собой набор классов,
загруженных из одного источника, с набором разрешений (Permission),
составляющих политику безопасности
• Локально загружаемые приложения по умолчанию считаются доверенными и
имеют полный доступ к системным ресурсам. Но можно их запустить и на
основе политики безопасности, как апплет или удаленное приложение
• Домены разделяются на системные и приложений.
• Все системные ресурсы JVM доступны только со стороны системных
доменов
• Ресурсы, которые составляют часть нити выполнения, трактуются как
домен приложения. Когда приложению нужны системные ресурсы, доступ к
ним, посредством кода системного домена, контролируется JVM
• Разрешение (Permission) – разрешение на доступ к именованному системному
ресурсу (файл, свойство, системная функция). Апплет или приложение используя
менеджер безопасности могут получить доступ к системному ресурсу только в том
случае, если имеют разрешения
• Включают в себя опциональных коллекцию действий (actions) над ресурсом,
доступ к которым разграничивается
• наследуются от java.security.Permission, уточняются для конкретного типа
ресурсов
• Java.security.AllPermission – разрешение на основе шаблона
 • Java.security.BasicPermission – именованное разрешение
• остальные от BasicPermission наследованные – FilePermission,
SocketPErmission, PropertyPermission, RuntimePermission, NetPermission,
AWTPermission
• Объект, используемый для защищенного доступа к другому объекту –
GuardedObject, создается на основе объекта и разрешения

GuardedObject guardedObj = new GuardedObject(openObject, new

PropertyPermission(“java.home”,”read”));
openObject = guardedObj.getObject();

• Политика безопасности (Policy) – определение политики безопасности

• Включает определение ограничений на
• набора доменов для исполняемого кода – откуда грузится и маски на
имена классов
• кем подписан код – ИД ключа
• тип разрешения с именем объекта и опционально действием
• Может определяться
• декларативно в текстовом файле из которого загружается при старте JRE
• в виде бинарного сериализованного представления классаPolicy
• Устанавливается
• Дефолтные для JVM в jre/lib/security/java.policy и для пользователя в
home/.java.policy. Расположение этих файлов определено в
jre/lib/security/java.security – системный файл свойств безопасности
• Дополнительная при запуске приложения через -Djava.security.policy, если
«=», то дополнительная складывается с дефолтной, если «==» - то
замещает ее
• Менеджер безопасности (Security manager) – определен для каждого
приложения или апплета, осуществляет загруженную политику безопасности
• Возбуждает AccessControlException и SecurityException
• Чтобы активизировать для обычного приложения надо
• запустить со свойством java.security.manager и опционально через
java.security.policy указать файл политики.
• Создать через new и установить через System.setSecurityManager,
используется дефолтная политика
• В приложении можно получать от System и использовать для проверки
возможности за счет методов
• множество checkXXXX - для контроля основных операций над файлами
• checkPermission – для проверки доступности разрешения в некотором
контексте
• Контроллер доступа (AccessController) –
• вызывается менеджером и динамически контролирует доступ к конкретному
ресурсу, то есть принимает решение о доступе прикладного кода к системному
ресурсу
• менеджер безопасности делегирует запросы на доступ к контроллеру и тот
выносит конечный вердикт
• Codebase – URL адрес класса или JAR файла, указывает на директорию или
адрес в интернете, откуда был загружен код
• представлен классом CodeSource, экземпляр создается на основе URL и перечня
сертификатов, которыми подписан код.
• Policy.getPolicy().getPermissions(codeSource) – дает перечисление разрешений для
кода в соответствии с установленной политикой безопасности. В процессе
 создания проверяется подпись кода исходя из сертификата, указанного в
политике
• Верификатор байткода (bytecode verifier) –
• проверяет соответствие байткода спецификациям JVM, осуществляет
дополнительные проверки типов и границ массивов
• по умолчанию включен для классов, загружаемых по сети. Можно включить или
отключить для всех классов
• Загрузчик классов (ClassLoader) – загрузка данных и конвертация их во
внутреннее представление классов JVM
• создается на основе URL, основной метод – loadClass(className)
• Загрузка координируется при помощи менеджера безопасности и контроллера
доступа в соответствии с политикой безопасности
• Обеспечивает распределение классов по пространству имен, а также по
источникам загрузки.
• Классы, загруженные из разных сетевых источников, внутри JVM друг с другом
не взаимодействуют.
• Инструментарий
• keystore - используется для хранения локальной файловой базы данных ключей
и сертификатов в соответствии со стандартом PKCS#12
• каждая ключевая пара идентифицируется уникальным алиасом – ИД (а
также сертификата, содержащего открытый ключ). Ключи хранятся
в .keystore файле, по умолчанию или указанном прямо. Доступ к закрытому
ключу контролируется паролем
• к каждому сертификату храниться цепочка ключей до самоподписанный
корневого сертификата от CA. Корневые сертификаты хранятся в cacerts
файле в директории security
• доступ к хранилищу и закрытому ключу защищается паролями
• keytool – средство управления парольно ключевой информацией
• используется для
• создания ключевого хранилища и JCEKS хранилища
• создания пар и сохранения ключевых пар
• работы с сертификатами в формате X.509
• импорта, экспорта и просмотра перечня
• генерации самоподписанных X.509 v1 сертификатов.
• Применения перечней отозванных сертификатов
• Формирования запросов на генерацию сертификатов и установки
корневых сертификатов
• Сертификат импортируется, если можно построить и проверить его цепочку
доверия до самоподписанного сертификата
• Просмотреть данные сертификата в виде отдельного файла можно и без
обращения к хранилищу
• Начиная с версии 5.0 есть возможность использовать смарт карты и
специализированные криптографические устройства для хранения ключевой
информации и выполнения операций
• Поддержка RSA Cryptographic Token Interface Standart – PKCS#11
• осуществляется специализированным модулем, выполняющим роль JCE
провайдера. По умолчанию это SunPKCS11
• jarsigner – используется для формирования и проверки подписи JAR файлов
• в своей работе использует указанное хранилище ключей
• при подписи в JAR файл вкладывается публичный ключ, парный к
закрытому, которым подписывали
 • для проверки подписи файла в хранилище должен быть установлен
соответствующий сертификат – для проверки открытого ключа
• policytool – используется для создания и модификации файлов политики
безопасности. Имеет GUI для работы с привилегиями
• Апплеты – java программы, запускаемые в контейнере веб просмотровщика в
контексте веб страницы
• Доверенные – загруженные с локальной файловой системы или с локального
хоста – полный доступ
• для подписанных апплетов в виде JAR файлов
• проверяется целостность на основе подписи и внедренного открытого ключа.
Сам открытый ключ проверяется предварительно установленным сертификатом
открытого ключа, выпущенным публичным поставщиком типа VerySign, Thawte
и т.д.
• применяется специальная политика безопасности заданная при запуске JVM для
просмотровщика апплетов или в системном файле свойств безопасности
• Для остальных - обязательное ограничение доступа к ресурсам JVM на
основе политики доступа. По умолчанию запрещено чтение и запись локальных
файлов, создание сетевых соединений с хостом, отличным от того, с которого
загружен апплет, запуск других программ, загрузка библиотек, вызов системного
кода
• WebStart – обычные java программы, которые для запуска могут быть загружены
или обновлены с веб сервера по протоколу JNLP
• Запуск обеспечивается специализированным приложением, интегрированным с веб
просмотровщиком. Раньше ставилось отдельно, начиная с версии 1.4 входит в J2SE.
После загрузки выполняются как обычные программы вне всякой связи с веб
просмотровщиком.
• В процессе загрузки контролируется подлинность и целостность файлов на основе
подписи и доверенного корневого сертификата в клиентском хранилище.
• Неопознанный код на машину не загружается.
• Если код прошел проверку пользователю выводятся данные сертификата и он
принимает решение о предоставлении программе привилегий
• Если код не подписан пользователь может ручками предоставить коду доступ к
ресурсам системы
• Выполнение контролируется JNLP дескриптором в виде XML документа,
расположенного на веб сервере и адресуемого пользователем, запускающим
приложение. В его составе указывается
• Источник кода, наименование приложения, производитель, описание
• Возможность offline работы
• Модель безопасности – all-permission / j2ee-application-client-permission
• Требования к JRE
• Перечень JAR модулей, составляющих приложение, для отдельной загрузки
каждого в случае обновления
• Smart Cards
• Java Card технология, стандарт ISO7816, представляет процессор и среду
исполнения для специализированных Java программ.
• Основной принцип– множество приложений одновременно работают с момент
установки до момента удаления вне связи с событиями активации карты
• Составляющие технологии
• Карта с процессором и
• Разделами памяти - ROM, RAM EPROM
• средой исполнения - операционная система, JCRE и необходимые API,
• прошиваются вендором в ROM
 • JCRE поддерживает
• защищенную среду выполнения с виртуальным файрволом,
разделяющим приложения, выполняемые на одной и той же карте
• выполнение приложения в песочнице, обеспечивающей безопасность
среды, в частности запрет вызова нативных методов
• загруженными в EPROM приложениями – апплетами вместе с их
постоянными данными и состоянием исполнение.
• Загрузка осуществляется при помощи средств вендора. При загрузке
приложения проверяются картой на целостность за счет внедренной
подписи
• Выполнение программ производится с использованием временной RAM,
обнуляющейся в момент отключения от карты питания.
• Если выполнение прекращено в случае отключения питания или
неизвестной ошибки – постоянные данные остаются в первоначальном
состоянии
• Приложения не видят друг друга, но могут обмениваться данными с
использованием специальных интерфейсов
• протоколом доступа к приложениям Application Protocol Data Units (APDUs).
Обмен состоит из команд ридера и ответов карты.
• Card reader or card acceptance device (CAD) – железный способ взаимодействия
терминала и карты, отправляет и получает команды с использованием протокола
• Терминал и прикладное программное обеспечение, которое запущено на нем и
взаимодействует с картой
• Часто применяется для
• Персональной идентификации и прав пользователей
• Защищенного хранения личной информации пользователей
• Хранения защищенной от копирования информации
• хранения данных, предназначенных для защиты обмена информацией через
публичные сети – интернет или телефонную
• выполнения криптографических операций

Java Cryptography Architecture (JCA)

• Терминология
• Электронная подпись (digital signature) – преобразование хэша данных и
произвольного набора свойств, например, времени формирования подписи, на
основе закрытого ключа.
• Не может быть создана без знания закрытого ключа
• При помощи открытого ключа может быть восстановлен хэш и сравнен с
имеющимися данными
• Контролирует целостность, обеспечивает аутентификацию подписавшего и его
неотрекаемость (non repudiation)
• Сертификат – открытый ключ владельца вместе с его формальным описанием в
формате ASN.1, удостоверенные подписью выпускающего (Issuer).
• Тот в свою очередь имеет свой сертификат, удостоверенный более высоким
выпускающим и так далее до CA сертификата – цепочка сертификатов
• каждый сертификат при создании характеризуется следующими свойствами
владельца (Owner), вместе составляющими DN (distinguished name)
• CN – first and last name
• OU – organizational unit
• O – organization
• L – city ot locality
• ST – state or province
 • C – country code
• Каждый сертификат характеризуется
• датой выпуска и периодом действия
• уникально - серийным номером и отпечатком – MD5 или SHA1 хэшом своих
данных
• Хэш данных – одностороння функция, на основе произвольной длинны набора
данных вычисляется фиксированной длинны свертка или отпечаток (fingerprint).
Обратное преобразование значительно затруднено. Ключей не использует. Примеры
алгоритмов – MD5, SHA
• Предоставляет основные криптографические сервисы и алгоритмы – формирование
хэшей, формирование и проверка подписей, генерация ключей
• Реализовано как рамочное API, поддерживающее подключаемые провайдеры
• Ответственность провайдера
• необходимые алгоритмы – хэширование, подпись и генерацию ключей
• реализации абстрактных классов подсистемы, представляющих основные
криптографические сущности – подписи, ключи, сертификаты и т.д.
• сервисы – генерацию и управлением хранилищем и ключами, управление
сертификатами, работа с параметрами алгоритмов
• провайдеров может быть установлено несколько, они могут использоваться
независимо или совместно
• Дефолтный провайдер от Sun выполняет
• хэширование – MD5 (16 байт) и SHA1 (160 бит)
• Генерация пары ключей на основе DSA и работа с подписями
• Работа с сертификатами на основе стандарта X.509, построение и проверка
цепочки сертификатов, работа CRL
• Файловое хранилище сертификатов и ключей – JKS
• Входные точки подсистемы
• Наследник java.security.provider – собственно провайдер, реализует
криптографические функции и алгоритмы. Регистрирует остальные сервисы,
предоставляемые провайдером, а также выдает системе необходимые
идентифицирующие провайдер метаданные
• Финальный класс java.security.Security – имеет только статические методы,
осуществляет управление всеми установленными провайдерами и свойствами,
относящимися к безопасности. Методы могут быть вызваны только доверенными
приложениями
• Абстракции подсистемы
• Хэш (java.security.MessageDigest) – осуществляет вычисление хэша данных,
основные этапы работы
• Получение реализации по алгоритму, выбрасывает NuSuchAlgorithmException
MessageDigest md5 = MessageDigest.getInstance(“MD5”);
• Добавление данные для вычисления
Md5.update(arrayOfByte)
• Вычисление
Byte[] result = md5.digest();
• Ключ (java.security.Key) – объектное представление ключа, создается генератором
или загружает фабрикой из общепринятого представления ключа
• Предоставляет методы получения ключа как массива байт, формата
сериализованного представления ключа и ид-а алгоритма к которому относится
ключ
• Наследники – PrivateKey и PublicKey для использования с ассиметричными
алгоритмами
 • Ключевая пара (java.security.KeyPair) – просто хранилище для пары ключей –
личного и открытого
• Подпись (java.security.Signature) – объектное представление подписи данных,
основные этапы работы
• Получение реализации по алгоритму, соответствующему для вычисления
закрытому ключу и для проверки открытому ключу
Signature dsig = Signature.getInstance(privateKey.getApgorithm())
• Инициализация для вычисления на основе закрытого ключа
Dsig.init(privateKey)
• Добавление данных
Dsig.update(testData)
• Формирование подписи
Byte[] signedData = dsig.sign()
• Инициализация для проверки на основе имеющейся подписи
Dsig.initVerify(publicKey)
• Добавление данных
Dsig.update(testData)
• Проверка подписи
Boolean result = dsigVerify(signedData)
• Генератор ключевой пары (java.security.KeyPairGenerator) – осуществляет
создание ключевой пары, основные этапы работы
• Получение реализации по алгоритму
KeyPairGenerator keyGen = KeyPairGenerator.getInstance(“DSA”)
• Инициализация – определение размера ключа. Для DSA от 512 до 1024 кратно 64
keyGen.initialize(1024)
• Генерация – получение ключевой пары, в ней ссылки на оба ключа
KeyPair keyPair = keyGen.getKeyPair()
• Фабрика ключей (java.security.KeyFactory) – конвертация ключей между
внутренним объектным представлением и общепринятым. Пример применения
• Получение описание закодированного ключа
X509EncodedKeySpec bobPubKeySpec = new X509EncodedKeySpec(encodedKey);
• Инициализация в соответствии с алгоритмом
KeyFactory keyFactory = KeyFactory.getInstance("DSA");
• Декодирование ключа
PublicKey bobPubKey = keyFactory.generatePublic(bobPubKeySpec);
• Хранилище ключей (java.security.KeyStore), основные методы
• Получение на основе статического метода getInstance с указанием типа
хранилища и опциональным провайдера
• Загрузка и сохранение в поток с указанием пароля – load / store
• Получение перечня алиасов входов – ИД-ов ключей / сертификатов в хранилище,
проверка наличия входа по его имени, выяснение типа входа – сертификат /
алиас
• Получение сертификата или цепочки сертификатов
• Загрузка сертификата
• Загрузка ключа с цепочкой сертификатов с указанием пароля
• Удаление входа – ключа или сертификата
• Параметры алгоритмов (java.security.AlgorithmParameters)
• Генератор параметров алгоритма (java.security.AlgorithmParametersGenerator)
– генерация подходящего для определенного алгоритма набора параметров
• Генератор случайного (псевдослучайного) числа (java.security.SecureRandom)

Java Cryptography Extensions (JCE)

• Часть первоначально выделенная в отдельное API, чтобы его можно было поставлять
опционально из-за ограничений США на экспорт криптографических средств.
 Опциональная для 1.2.х и 1.3.х и вследствие изменения в законодательстве вошедшая в
1.4 и далее. Также реализовано как рамочное API, поддерживающее подключаемые
провайдеры
• Основное дополнение по сравнению с JCA- поддержка шифрования, как
симметричного, так и ассиметричного, включая потоковое и объектное («sealed
objects»)
• Поддержка advanced encryption standard (AES) – симметричное
шифрование с ключами 128, 192, 256 бит данных в блоках по 128 бит
• Алгоритмы симметричного – DES (FIPS PUB 461), TripleDES, Blowfish
• Алгоритмы ассиметричного – RSA.
• Минус - Примерно в 1000 раз медленнее, чем симметричное
• Плюс – не нужен специальный канал распределения ключей
• Блоковое шифрование
• Режимы - Electronic Code Book (ECB), Cipher Book Chaining (CBC), Cipher
Feedback (CFB), Output feedback (OFB), Propagation Cipher Book Chaining (PCBC)
• Схема дополнения случайными данными до фиксированной длинны - PKCS#5
• Шифрование на основе пароля (PBE)
• Остальные дополнения
• Реализация MD5 на основе алгоритма шифрования на основе пароля (PBE) DES-
CBC
• Генерация ключа дополнительных алгоритмов, работа с параметрами
• Работа с ключами для шифрования данных между несколькими пользователями –
Diffie-Hellman.
• MAC алгоритмы для контроля целостности информации, передаваемой между
участниками, на основе хэширования и секретного ключа, алгоритмы HMAC-MD5,
HMAC-SHA1
• Поддержка AES –нового алгоритма, применяемого для шифрования электронных
данных, симметричный, блоковый по 128 бит, длинна ключей - 128/192/256 бит.
Предполагается как замена DES, быстрее чем TripleDES
• Поддержка собственного ключевого хранилища – JCEKS
• Дополнения начиная с версии Java 5
• Поддержка PKCS#11 – интерфейса для работы с устройствами, которые хранят
криптографическую информацию и/или производят криптографические операции –
смарт карты, акселераторы и т.д.
• Поддержка алгоритма шифрования на эллиптических кривых ECC
• Поддержка XML шифрования в стандарте RSA-OAEP
• Интеграция с криптографической подсистемой Solaris
• Поддержка алгоритма симметричного шифрования RC2 и ARCFOUR
• Абстракции подсистемы и их использование
• Шифр (javax.crypto.Cipher)
• Шифрование
• Генерация ключа
KeyGenerator kgen = KeyGenerator.getInstance(“DES”)
SecretKey skey = kgen.generateKey()
• Создание шифра – алгоритм / блочный режим / заполнение
Cipher mycip = Cipher.gteInstance(“DES/ECB/PKCS5Padding”)
• Инициализация и шифрование
Mycip.init(Cipher.ENCRYPT_MODE, skey)
Byte[] cipText = mycip.doFinal(openText)
• Инициализация и дешифрование
Mycip.init(Cipher.DECRYPT_MODE, skey)
Byte[] openText = mycip.doFinal(cipText)
• Шифрование на основе пароля (PBE).
 • Чтобы создать ключ кроме пароля надо иметь большое случайное число –
seed и число итераций – count. На обоих сторонах числа и пароль должны
использоваться одни и те же
PBEParamSpec pbeParamSpec = new PBEParamSpec(seedByteArray, count)
PBEKeySpec pbeKeySpec = new PBEKeySpec(password);
SecretKeyFactory keyFactory = new SecretKeyFactory.getInstance(“PBEWithMD5AndDes”)
SecretKey pbeKey = keyFactory.generateSecret(pbeKeySpec);
Cipher pbeCipher = Cipher.getInstance(“PBEWithMD5AndDes”)
pbeCipher.init(Cipher.ENCRYPT_MODE, pbeKey, pbeParamSpec)
• Потоковое симметричное шифрование (javax.crypto.Cipher[Input|
Putput]Stream)
CipherOutputStrem cos = new CipherOutputStream(outputFileStream, mycip)
Cos.write(byteArray);
• Хэш сообщения на закрытом ключе (javax.crypto.Mac)
Mac mac = Mac.getInstance(“HmacMD5”)
Byte[] digest = mac.doFinal(messageBytes)
• Генератор симметричных ключей (javax.crypto.KeyGenerator)
• Фабрика симметричных ключей (javax.crypto.SecretKeyFacory)
• Шифрованный объект (javax.crypto.SealedObject)
SealedObject sealedObject = new SealedObject(openObjecy,myCipher)
openObjecy = sealedObject.getObject(myCypher)
• Соглашение о ключах (javax.crypto.KeyAgreement)
• Средство защиты передаваемой по открытому каналу информации на основе
симметричного шифрования. Протокол Diffie-Hellman (DH) позволяет двум или
более пользователям обменяться закрытым ключом без какого-либо
предварительного знания друг о друге
• Общая схема работы - каждая из сторон обмена должна
• создать и инициализировать ключевую пару на основе трех параметров:
• начальный модуль (prime module) p и base generator g - открытые
параметры, зашитые или установленные случайно и переданные открыто
• размер в битах l - закрытый параметр
KeyPairGenerator keyGen = KeyPairGenerator.getInstance(“DH”);
DHParameterSpec dhSpec = new DHParameterSpec(p,g,l);
keyGen.initialize(dhSpec)
KeyPair keyPair = keyGen.generateKeyPair();
• Открытый ключ отсылается другой стороне, в ответ принимает ее открытый
ключ
PublicKey publicKey = keyPair.getPublic()
PrivateKey privateKey = keyPair.getPrivate()
Byte[] publicKeyBytes = publicKey.getEncoded()
Send(publicKeyBytes)
publicKeyBytes = receive();
• Восстанавливается полученный публичный ключ из байтового потока
X509EncodedKeySpec spec = new X509EncodedKeySpec(publicKeyBytes);
KeyFactory keyFactory = KeyFactory.getInstance(“DH”)
publicKey = keyFactory.generatePublic(spec)
• Создается закрытый ключ для симметричного шифрования передаваемых
данных на основе соглашения KeyAgreement
KeyAgreement ka = KeyAgreement.getInstance(“DH”);
Ka.init(privateKey)
Ka.doPhase(publicKey, true); - используется открытый ключ ДРУГОЙ стороны
SecretKey secretKey = ka.generateSecret(“DES”)
• Использование смарт карт, акселераторов и других устройств
• Необходимо инсталлировать PKCS#11 провайдер с указанием класса провайдера и
его конфигурационного файла со свойствами, определяемыми вендором
• статически через файл свойств jre/security/java.security
 • программно через создание его экземпляра вручную как new и регистрацию
через Security.addProvider(provider)
• При необходимости использовать смарт карту в качестве хранилища ключевой
информации устанавливаются необходимые значения системных свойств. После
чего все приложения и инструментарий прозрачно начинают работать с новым
хранилищем
• Провайдер для этого уже должен быть установлен
• Для утилит может потребоваться указание типа хранилища и используемого
провайдера, пин к карте передается как пароль к хранилищу

Производные API на основе JCA/JCE

• Java Certification Path API (CertPath) – работа с цепочками доверия для
сертификатов от Certification Authority (CA) до имеющегося проверяемого. Работает на
основе JCA / JCE провайдеров
• Хранение, разбор и проверка сертификата, построение и проверка целостности
цепочки, работа с перечнем отозванных сертификатов (CRL)
• начиная с Java 5 – клиентская поддержка OCSP протокола для оперативной
проверки статуса сертификата без необходимости получения и разбора всех CRL
• основная проблема работы с сертификатами – проверка факта того, что
сертификат не был отозван или скомпрометирован. Средства решения – OCSP
сервера и CRL списки
• Основные сущности в пакете java.security.cert
• Цепочка сертификатов - CertPath
• Фабрика создания сертификатов и CRL из их сериализованного представления -
CertificateFactory
• Построитель цепочки сертификатов – CertPathBuilder
• Валидатор цепочки сертификатор – CertPathValidator
• Хранилище сертификатов и ключей – CertStore. Также предоставляет методы
поиска сертификатов и CRL на основе CertSelector и CRLSelector
• Доверенный корневой сертификат от CA – TrustAnchor
• Параметры алгоритма проверки целостности цепочки сертификатов –
PKIXParameters – селектор на проверяемые сертификаты, перечень
обязательных OID, доверенный СA сертификат и так далее
• Основные операции
• Построение цепочки сертификатов
CertificateFactory certFact = CertificateFactory.getInstance(“X.509”)
CertPath certPath = certFact.generateCertPath(List<Certificte>)
• Проверка цепочки сертификатов
• Загрузка хранилища
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType())
keyStore.load(fileInputStream, password)
• Создание параметров проверки
PKIXParameters params = new PKIXParameters(keyStore)
Params.setRevocationEnabled(false);
• Создание валидатора и проверка
CertPathValidator validator =
CertPathValidator.getInstance(CertPathValidator.getDefaultType())
CertPathValidatorResult res = validator. Validate(certPath, params)
• Выявление для цепочки корневого сертификата
CACert = res.getTrustAnchor().getTrustedCErt();
• Java Security Socket Extension (JSSE) – защищенные сокеты.
• Возможности - шифрование данных, серверная аутентификация, контроль
целостности сообщений, опциональная клиентская аутентификация
 • Реализация SSL 3.0 / TLS 1.0 вместе с основными шифрами для поддержки
аутентификации, соглашения по ключам, шифрования и проверки целостности
• SSL / TLS машина состояний (SSLEngine) для буферной обработки данных,
поддержки неблокирующих соединений и т.д., начиная с 5.0
• Поддержка RSA алгоритма, работа с его ключами – генерация и фабрика
создания
• X.509 управление ключами и сертификатами для JCA
• Поддержка Kerberos, если базовая ОС это позволяет – начиная с версии 5.0
• Поддержка PKCS#11 – начиная с версии 5.0
• На основе этого работают SSL/TLS, используя как симметричное на
основе ДХ, так и ассиметричное шифрование. Дальше протоколы более высокого
уровня
• Secure HTTP (HTTP over SSL)
• Secure shell (telnet over SSL)
• Secure SMTP (SMTP over SSL)
• IPCES (Secure IP)
• Secure RMI or RMI/IIPO (RMI over SSL)
• Также рамочное API. По версию 1.4 дефолтный провайдер – SunJSSE,
поставляющийся в составе JCA. Начиная с версии 5 – в качестве базового
используется JCE. Провайдеров можно регистрировать либо статически, либо
программно
• Основные сущности
• Фабрики создания сокетов, клиентская и серверная – SocketFactory /
ServerSocketFactory
• Фабрики создания SSL сокетов, клиентская и серверная – SSLSocketFactory /
SSLServerSocketFactory
• SSL сокеты, клиентский и серверный – SSLSocket / SSLServerSocket
• SSLEngine – реализация машины состояний, обеспечивающий транспортно
независимый механизм защищенного обмена данными через SSL/TLS на основе
шифруемых буферов
• SSLSession – описание сессии обмена данными, в ней хранятся адреса сторон,
используемые ключи и сертификаты, времена и сессионные объекты. При работе
с сессией используются SSLSessionBindingListener / SSLSessionBindingEvent –
слушатель сессии и событие, описывающее помещение и удаление объекта из
контекста сессии
• SSLSessionContext – коллекция всех сессий и общие параметры – расзмер кэша
памяти для сессий и таймаут
• TrustManager – менеджер, определяющий являются ли предъявленные
удаленным приложением данные достаточными для аутентификации, то есть
доверенное оно или нет. Создается фабрикой TrustManagerFactory, реализация
которой поставляется провайдером
• HttpsURLConnection – реализация HttpURLConnetion соединение по HTTP,
защищенное на основе SSL/TLS. Используется HostnameVerifier – callback
интерфейс, позволяющий зарегистрировать модуль проверки связи хоста с
сессией.
• Аутентификация
• Клиент всегда аутентифицирует сервер. Требуется, чтобы
• на сервере были созданы ключи и серверный сертификат был в хранилище
клиента.
• Используемые хранилища ключей и сертификатов был прописаны через
системные свойства, специфичные для ssl
 • Сервер аутентифицирует клиента, взаимная или mutual. Требуется, чтобы
каждый имел сертификат другого. Управление со стороны сервера
• SSLServerSocket.setNeedClientAuth – требование для клиента предоставить
в процессе идентификации собственный сертификат
• SSLServerSocket.setWantClientAuth – возможность для клиента
предоставить в процессе идентификации собственный сертификат
• Основные операции
• SSL сервер использует хранилище с парой ключей. Расположение используемого
хранилища определяется системным свойством javax.net.ssl.trustStore
• клиент предварительно должен иметь сертификат сервера вместе со всей
цепочкой до CA, чтобы проверить его идентичность.
• Создание клиента
• Регистрация провайдера
Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider())
System.setProperty(“javax.net.ssl.trustStore”,name)
System.setProperty(“javax.net.ssl.trustStorePassword”,password)
• Создание SSL сокета
SSLSocketFactory factory = SSLSocketFactory.getDefault()
SSLSocket socket = factory.createSocket(host, port);
• Создание потоков для обмена данными
OutputStream out = socket.getOutputStream();
InputStream in = socket.getInputStream();
• Создание сервера
• соответственно используются серверные сокеты и фабрики сокетов
• обслуживание клиента производится в цикле
SSLSocket sslSocket = sslServerSocket,accept();
InputStream is = sslSocket.getInputStream()
InputStreamReader isr = new InputStreamReader(is);
BufferedReader br = new BufferedReader(isr)
• HTTPS = HTTP / SSL
• Регистрируем SSL провайдер
• Регистрируем поддержку протокола HTTPS для разбора URL
System.setProperty(“java.protocol,handler.pkgs”,
“com.sun.net.ssl.internal.www.protocol”)
• Создаем стандартное соединения, в адресе должен быть префикс “https://’
HttpsURLConnection conn = (HttpsURLConnection) new
URL(“https://host”).openConnetion();
• Проверка наименования хоста, с которым в итоге установилось соединения –
установить для соединения реализацию интерфейса HostnameVerifier с
логикой проверки наименования хоста
• Поддержка прокси
• Либо через системные свойства https.ProxyPort / https.ProxyHost
• Либо программно
conn.setSSLSocketFactory(new SSLTunnelSocketFactory(host, port))
• Java Generic Secure Service (JGSS)
• Опциональное, предоставляет пользователям унифицированное API для
работы с различными системами аутентификации (например Kerberos), поддержку
SSO
• Сравнение с JSSE / JAAS
• Возможность организации SSO за счет использования всеми приложения
Kerberos как механизма аутентификации.
• Возможность работы поверх любого транспортного механизма за счет
использования токенов
 • За счет использования Kerberos позволяет клиенту делегировать свою
идентичность приложению, работающему на сервере
• Дополнительные типы данных, подтвержденные токеном, для поддержки
приложений, которым требуется распространять текстовые и шифрованные
приложения
• Simple Authentication and Security Layer (SASL)
• Протокол, предназначенный для аутентификации и защищенного обмена данными
между приложениями на клиенте и сервере.
• Появился начиная с Java5, тоже рамочное API + провайдеры аутентификации
• Используется протоколами, ориентированными на создание соединения - LDAP v3,
IMAP v4, SMTP, FTP, telnet, ACAP
• Ход аутентификации
• Наименование требуемого механизма задается клиентом в команде
аутентификации,
• если сервер поддерживает его, то он высылает в ответ серию окликов
«challenges», на которые клиент должен послать определенные ответы до тех
пор, пока сервер не пришлет подтверждение аутентификации
• в результате клиент получает ИД, производится договоренность о выбранном
транспортном протоколе, размере буферов обмена и т.д.
• Подвержен атаке методом «человек в середине», который может подменить
механизм, заданный клиентом, на наименее защищенный

Java Authentication and Authorization Service (JAAS)

• Предоставляет API и инфраструктуру на основе подключаемых провайдеров
для выполнения операций по аутентификации и авторизации пользователей.
• Java реализация Pluggable Authentication Module (PAM) фрейморка, первоначально
разработанного для соляриса.
• Позволяет устанавливать расширения, реализующие различные механизмы
аутентификации – Kerberos, RSA, Smart cards, биометрические системы и т.д. На их
основе обеспечивает механизм идентификации исполнителя кода
• По результатам аутентификации позволяет определять правила доступа и
привилегии для выполнения функций. Расширяет JVM контроль доступа на основе
codesign / codebase возможностью разграничивать доступ на основе идентификации
выполняющего код
• Структура фрейморка
• Основные базовый классы
• Субъект идентификации / аутентификации (Subject) – группа людей,
организаций или сервисов, которым выдано множество полномочий (мандатов)
на доступ к каким-то функциям системы. После выполнения аутентификации
оказывается ассоциированным с набором принципалов (пользователей)
• Принципал (Principal) – пользователь, представляющий часть возможностей,
доступных субъекту. Определено хранение только имени.
• Аутентификация
• Контекст логина (LoginContext) – фасадный класс, предоставляющий основной
набор методов для выполнения аутентификации субъекта. В процессе
аутентификации загружает конфигурацию, создает модули логина и вызывает их
функции в заданной конфигурацией последовательностью, передавая им
созданный приложением хэндлер обратного вызова, для осуществления
взаимодействия с пользователем
• Модуль логина (LoginModule) – имплементация предоставляется каждым JAAS
провайдером и реализует какую-то технологию идентификации /
аутентификации пользователя.
 • Декларативно конфигурируется в контексте логина для каждого процесса
аутентификации отдельно
• Работает, взаимодействуя с
• субъектом, который в случае удачи набиваем созданными принципалами
• с хэндлером обратного вызова, представленного приложением, который
реализует логику запроса необходимой информации от пользователя
• Конфигурация (Configuration) – загружается контекстом логина из текстового
файла, служит для создания и конфигурирования перечня модулей логина,
последовательный вызов которых реализует процесс аутентификации
• Хэндлер обратного вызова (CallbackHandler) – интерфейс, реализация
которого предоставляется приложением и контекстом доводится до каждого
модуля в поэтапном процессе выполнения аутентификации. За счет хэндлера
модуль может передать пользователю описания операции запроса какой-то
информации (Callback), которую пользователь выполняет в меру доступной ему
функциональности. Например, запрос логина / пароля.
• Интерфейс запроса у пользователя необходимой для аутентификации
инфорамции (Callback) – формализованное представление операции запроса,
например «приглашение к вводу» + «ответ пользователя». Прикладное
приложение, активизированное за счет хэндлера, должно этот запрос выполнить
в соответствии с его логикой и собственными возможностями. Примеры
запросов - ChoiceCallback, ConfirmationCallback, LanguageCallback,
NameCallback, PasswordCallback
• Авторизация
• Политика (Policy) – системная политика контроля доступа к ресурсам системы.
По сравнению со стандартом, определяющим разграничение доступа для
множества кода в целом, уточнена до уровня отдельным принципалов,
выполняющих данный код.
• Разрешение на аутентификацию (AuthPermission) – основа для разрешений,
необходимых для пользования JAAS, предоставляющих доступ к политике,
субъекту, контексту и конфигурации. В частности, если коду выдана привилегия
AuthPermission “setPolicy”, то он может устанавливать текущую политику
безопасности
• Разрешение на доступ к набору полномочий субъекта
(PrivateCredentialsPermission). В частности определяет возможность
использования методов doAs и doAsPrivileged, изменять сам состояние субъекта
и т.д.
• Логика аутентификации
• Клиент запускает процесс аутентификации путем создания контекста, на основе ИД
конфигурации и собственной реализации интерфейса хэндлера обратного вызова.
Хэндлер реализует запросы каждого логин-модуля на предоставление необходимой
для процесса информации в соответствии с технологией и дизайном приложения.
• Вызывается метод аутентификации контекста. Контекст считывает конфигурацию,
создает и конфигурирует набор модулей и субъекта
• Последовательно вызываются модули. При вызове модулю передается субъект, map
разделяемой между модулями информации и хэндлер
• Каждый модуль в процессе в процессе работы за счет хэндлера запрашивает у
пользователя необходимую ему информацию, выполняет ее проверку с точки зрения
конкретного механизма аутентификации, может часть информации передать другим
модулям, например для осуществления SSO, информирует контекст о результате.
• Контекст на основании вызова всех модулей принимает решения об успешности
процесса в целом.
• Если sufficient флаги не выставлены успешность в целом достигается если все
required / requisite подтвердили
 • Если нет required / requisite флагов, то по меньшей мере один sufficient или
optional должен подтвердить
• Последовательно вызываются все модули, которые либо чистят набор принципалов
для субъекта, либо создает и присоединяет к нему набор необходимых принципалов
сформированный в соответствии с внутренней логикой
• Основные задачи процесса аутентификации
• Реализация модуля логина, все следующие операции вызываются контекстом
• Инициализация (void initialize(Subject, CallbackHandler, sharedMap,
configMap)) –
• прикапываем переданные в аргументах ссылки на субъект, хэндлер,
разделяемое между всеми модулями состояние процесса в целом и
конфигурационные опции для конкретного модуля
• чистим хранимое состояние – флаг успешности этапа, набор присвоенные
субъекту принципалов
• Выполнение аутентификации (boolean login()) – выполнение этапа процесса
аутентификации
• Создается массив запросов, который передается операции handle(Callback[])
хэндлера обратного вызова, ссылка на который была прикопана ранее.
• Операция дергает код клиента, который выбирает отдельные запросы
Callback и их исполняет.
• После выполнения операции из запросов извлекаются введенные
пользователем данные и выполняется процедура аутентификации.
• Данные могут быть прикопаны в разделяемом состоянии для использования
другими модулями, что обеспечивает возможность реализации SSO. Для
обеспечения этого должно быть установлено свойство модуля
«useSharedState=true»
• Результат этапа прикапывается, контексту возвращается true, либо
возбуждается LoginException
• Подтверждение аутентификации (boolean commit()) – вызывается, если
контекст принял решение об успешной аутентификации клиента
• В случае, если данный этап был выполнен успешно создается массив
принципалов и добавляется к уже имеющемуся у субъекта. Массив
принципалов прикапывается, чтобы потом в случае чего отобрать
• Результат этапа возвращается контексту
• Прекращение процесса аутентификации (Boolean abort()) – выполняется, если
контекст принял решение о неуспешности процесса в целом
• Хранимое состояние чистится, все принципалы у субъекта отзываются
• Результат этапа возвращается контексту
• Выход клиента (Boolean logout())) - Хранимое состояние чистится, все
принципалы у субъекта отзываются
• Конфигурирование
• декларативное – через свойства в общем файле безопасности
jre/lib/security/java.security, задаются класс провайдеров модулей и расположение
единого для всех приложений конфигурационного файла.
• Дополнительно для отдельного приложения конфигурационный файл может
быть задан через системное свойство
• Формат файла
BiometricLogin {
Aaa.bbb.ModuleLogin1 sufficient
eee.ccc.ModuleLogin2 optional parameter=value
}
• В конфигурационном файле задается для именованной конфигурации контекста
перечень этапов аутентификации. Для каждого этапа:
 • Класс модуля логина
• Набор конфигурационных опций для модуля в формате
<наименование>=<значение >
• Флаг обработки результат вызова модуля
• Required – для успешности в целом модуль должен подтвердить
аутентификацию, в любом случае процесс продолжается
• Requisite - для успешности в целом модуль должен подтвердить
аутентификацию, в случае неуспешности вызова процесс прекращается
• Sufficient – если модуль подтвердил аутентификацию, то этого
достаточно и процесс прекращается. Если нет – продолжается дальше,
может кто другой подтвердит
• Optional – от модуля обязательного подтверждения не требуется, для
успешности в целом обязательного подтверждения не требуется.
• Реализация клиента
• Создать реализацию CallbackHandler, для этого реализовать единственную
функцию handle(Callback[]) которая выполнит все действия из набора.
• Действие распознается на основе «instance of»
• Например, для PasswordCallback предъявить пользователю приглашение из
свойство «prompt», принять от него строку и упаковать ее обратно в действие
в свойство «password»
• Создать контекст за счет конструктора, которому передается ИД конфигурации
контекста (должен быть определен в файле конфигурации JAAS для JRE в целом
или в конкретного приложения) и экземпляр CallbackHandler
• Вызвать функцию login контекста и в случае успешности получить субъект за
счет вызова метода getSubject контекста
• За счет исследования Subject можно определить выданный набор возможностей,
множество стоящих за ним принципалов и так далее
• Логика авторизации
• Авторизация производится на основе стандартной системы пользователей, групп и
ролей. В переводе: пользователь = Subject, группа = Principal, роль = Permission
• Условия процесса авторизации
• Subject должен быть аутентифицирован, должна быть определена
• политика доступа в специальном Policy файле на основе отдельных Principal,
grant <signers>, <codebaseURL>
Principal “principalName” {
Permission permissionClass “permissionName”, “operation”;
}
• вызов должен осуществляться в контексте Subject за счет статических методов
doAs и doAsPrivileged, которым передается
• Subject от имени которого выполняется операция
• Действие в виде PrivilegedAction<T> или PrivilegedExceptionAction<T>, у
которого определен метод выполнения действия как T run()
• Выполняемый код может получить объект Subject текущего процесса, если у
него есть такие привилегии
• Управляющий код может, если у него есть необходимые права:
• Обновлять текущую политику безопасности за счет статического метода
Policy.setPolicy. Например, реализация может использовать для хранения
политик не файл, а базу
• Управлять состоянием объекта Subject, например, динамически менять перечень
принципалов в соответствии с изменяющимися настройками системы
• Описание процесса авторизации
Архитектура безопасности J2EE
• Ключевая особенность
• инфраструктура поддерживает безопасность обмена запросами и ответами на всех
уровнях ПО по всей цепочке взаимодействия: от клиента до последнего компонента
и далее в слой ресурсов.
• При этом клиент аутентифицируется только раз при первом запросе, дальше его
идентичность и сопутствующие данные в течении всей сессии работы
автоматически сопровождают все его вызовы и передаются через все слои как
контекст вызова
• Одна и та же модель безопасности для всех компонентов на всех уровнях
• Недостаток – отсутствует стандартная модель аудита
• Роли и ответственности
• Platform provider – вендор, ответственный за реализацию J2EE стандарта. Его задача
осуществить мапинг привилегий на методы бизнес компонентов, а также на
системные сервисы и ресурсы окружения
• контейнера - предоставить пользователю, имеющему какую-то роль,
соответствующие привилегии по доступу к методам бинов / путям веб приложения
• Application Developer – определяет роли, то есть выделенную совокупность
потенциальных пользователей компонента, и ограничения на их основе по доступу к
методам компонентов
• Application Assembler – определяет представление системы в целом с точки
безопасности, устанавливая зависимости между компонентами
• Application Deployer – связывает роли приложения с принципалами
(аутентифицированными пользователями / группами) среды, в которой оно
развернуто
• Термины
• Principal – сущность, которая была аутентифицирована в рамках какой-то области
(realm). Обычно связывается в процессе аутентификации с каким-то пользователем,
который либо входит в группу, имеющую ролью, либо просто обладает самой ролю
• Security Realm / Policy Domain – домен или область безопасности, совокупность
политики безопасности и идентификационных механизмов (пользователей, групп и
ролей), задействованных вместе для защиты некоторого множества ресурсов.
• Security Attributes – свойства принципалов, зависящие от специфики приложения, на
основании которых принимаются решения при авторизации и которые идут в запись
лога
• Security Credential – удостоверение / мандат, информация, относящаяся к процессу
аутентификации принципала, какая именно – зависит от механизма аутентификации
• Роль – группа привилегий на доступ и выполнение каких-то операций над ресурсом,
выделенная сборщиком приложения и выдаваемая группе или пользователю как
единое целое
• Группа – множество аутентифицированных пользователей, связанных в единый
набор в соответствии с какими-то характеристиками
• Сервисы инфраструктуры, связанные с безопасностью
• Поддержание доменов безопасности для защиты ресурсов на основании
пользователей, групп и списков контроля доступа (ACL). На инфраструктуру
возлагаются ответственности
• Осуществление аутентификации, когда вызов пересекает границу домена
• Перенос идентичности вызывающего, когда вызов производится внутри домента.
Таким образом компоненты могут доверять друг другу в вопросе безопасного
вызова
• Передача идентичности уже аутентифицированного вызывающего, когда вызов
уходит в следующий контейнер
 • Разграничение доступа к ресурсам на основе идентичности вызвающего
• Механизмы аутентификации, основные – на базе логина / пароля (пароли могут
быть одноразовые, вырабатываемые token device) и на базе идентичности X.509
сертификатов, предоставляемых сторонами как часть SSL аутентификации
• На основе контейнера – декларативно конфигурируется и автоматически
осуществляется инфраструктурой J2EE сервера
• для всех клиентов, так или иначе идущих через веб контейнер
• Для стандартных веб приложений и веб сервисов
• Для обычных приложений, которые работают не напрямую с EJB, а через веб
компоненты
• На основе приложения – программно, на приложение возлагается обязанность
самостоятельного сбора данных и осуществления аутентификации
• На основе агентов – полагается на агенты, в основном для поддержки SSO,
взаимодействия с порталами, бизнес приложениями и т.д. Обычно реализуются
как прокси, обрабатывающие пользовательские запросы к J2EE серверу, или как
подключаемые JAAS модули
• Предоставление возможности SSO между всеми приложениями в рамках одного
домена безопасности
• Авторизация доступа пользователей и групп к ресурсам
• Декларативный
• на основе статической политики в виде записей в XML дескрипторах EAR
для приложения в целом, JAR для EJB модуля, WAR, JAR для клиентского
приложения.
• Проще, но более грубый, осуществление возлагается на инфраструктуру,
перестройка на ходу не возможна
• разграничение для веб приложений на уровне отдельных URL-ов и методов
(GET/POST) обращения, для EJB - вызываемых методов
• Программный - сложнее, решение может быть принято динамически с
использованием произвольной бизнес логики и на основании свойств, как
защищаемого ресурса, так и принципала.
• Поддержания целостности и конфиденциальности данных при их передаче на
основе SSL/TLS протоколов.
• Поддержка как веб, так и EJB компонент - http и RMI/IIOP поверх SSL.
• Обязанность сборщика приложений определить через дескриптор компоненты,
методы которых должны быть вызваны под подобной защитой. В дальнейшем
взаимодействие поддерживается автоматически
• Аудирование и логирование событий системы, связанных с безопасностью
• Фильтрация входящих сетевых соединений от клиентов на основе имени / адреса
хоста или протокола
• Поддержка подключаемых посредством JAAS модулей предоставления сервисов
аутентификации и авторизации
• Поддержка для контейнеров подключаемых модулей осуществления авторизации –
Java Authorization Contract for Container (JACC). Обязательная часть J2EE 1.4
• Поддержка модулей сторонних производителей для взаимодействия с веб
серверами, порталами и другими бизнес приложениями
• Конфигурирование доменов безопасности и пользователей на основе файлов, LDAP
и базы данных
• Безопасность по уровням и компонентам
• Веб компоненты
• Предоставляемые инфраструктурой сервисы – аутентификация, авторизация,
стандартный механизм логина, поддержка безопасности сессии, безопасность на
транспортном уровне, SSO для интеграции нескольких приложений
• Аутентификация должна быть сконфигурирована для веб приложения в файле в
web.xml перед его развертыванием за счет тегов security-constraint, login-config,
auth-method, realm-name
• HTTP Basic (BASIC) – через диалог браузера
• единственный при котором можно указать realm
• данные передаются в BASE64 кодировки, поэтому метод безопасен
только ПОСЛЕ установления SSL соединения. Конфигурируется в том же
дескрипторе как метод передачи данные как CONFIDENTIAL
(защищенный от раскрытия) / INTEGRAL (не допускающий изменения)
• Form Based (FORM) – то же самое, но можно использовать произвольные
форма ввода логина / пароля и вывода сообщения об ошибке
• Теги – form-login-config, form-login-page, form-error-page
• Стандартные поля формы j_username, j_password и URL поля
j_security_check
• Client / Server mutual (CLIENT-CERT) на основе обмена X.509 сертификатами
в процессе установления SSL соединения
• HTTP Digest (DIGEST) тоже через диалог браузера, но на сервер
пересылается не пароль в открытом виде, а его хэш.
• Слабая защита, точно также требует SSL соединения
• Опционально поддерживается браузерами и серверами
• Могут быть подключены дополнительные JAAS модули, осуществляющие
аутентификацию на основе введенных пользователем или выделенных из
сертификатов данных.
• Принцип – один LoginModule на один Realm, конфигурирование средствами
вендора
• Они могут соединяться с файлами данных, LDAP, NT Realm, RDBMS и так
далее
• Поддержка SSO
• Пользователь экономит время за счет того, что сразу выходит и выходит из
всего множества приложения
• Функция идентификация выносится в специализированнее приложение
• методы
• на основе Куков в любом случае
• на основе множественности JAAS модулей для приложений развернутых
в одном контейнере, по одному модулю на приложение, который делят
между собой один раз установленную идентичность пользователя
• поддержка модулей сторонних производителей
• внедряются как агенты в веб сервер и соединяются со своими провайдерами
информации
• позволяют приложению абстрагироваться от типа используемого
аутентификационного механизма
• Поддержка сессий
• Необходимость шифрования / подписи Куков или перекодированных URL с
включением обязательной информации
• Идентифицирующей сетевой адрес клиента
• Время создания
• Критично для безопасности – вовремя прибивать сессии пользователя по
таймауту или при операции логаута
• Авторизация
• Декларативная - security-constraint (web-resource-collection (web-resource-
name, url-pattern, http-method), auth-constraint (role-name))
 • Программная – методы HttpRequest – getRemoteUser / isUserInRole /
getUserPrincipal
• J2EE клиенты
• Основные методы взаимодействия с сервером
• Поверх HTTP напрямую к JSP / Servlet или с использованием JAX-
RPC(SOAP-RPC) при работе с веб сервисами.
• Аутентификация достигается за счет установления SSL соединения,
идентичность за счет инфраструктуры проносится по всей цепочке вызова
• RMI/IIOP напрямую к EJB
• Аутентификация за счет использования JAAS LoginContext, далее создаем
JNDI InitialContext и через него все вытаскиваем
• Развернуты в клиентском контейнере (ACC), который предоставляет сервисы для
обращения к компонентам на сервере – EJB, очередям сообщений и т.д.
Контейнер + классы приложения упакованы в единый JAR, содержащий
application-client.xml
• Бизнес компоненты
• Аутентификация
• идентичность уже установлена веб слоем, то есть веб контейнер и EJB
контейнер составляют единый домен безопасности
• для толстого клиента устанавливается за счет JAAS при получении доступа и
передается через протокол Corba / RMI-IIOP
• Декларативная авторизация – в ejb-jar/assembly-descriptor
• Определение роли – security-role
• Предоставление доступа к методу – method-permission(role-name, method (ejb-
name, method-name)*)
• Запрещенные для доступа методы – exclude-list(method (ejb-name, method-
name)*)
• Метод со свободным доступом - method-permission(unchecked, method (ejb-
name, method-name)*)
• Программная авторизация – методы EjbContext - isCallerInRole /
getCallerPrincipal
• Передача идентичности при вызовах
• Поддерживается при дальнейших вызовах между несколькими EJB
серверами
• Передается либо идентичность пользователя, либо заданная в session/security-
identity(run-as|user-caller-identity). Особенно удобно, если дальнейшее
управление надо передать, ограничив вызывающего пользователя в правах
или предоставить возможность пользователю выполнить администрирующее
действие не давая ему полный набор прав администратора.
• Веб сервисы
• Безопасность осуществляется как на уровне клиента, так и на уровне сервера
• По уровням
• Транспортный – SSL/TLS, аутентификация BASIC над SSL, и на основе
сертификатов взаимная
• На уровне сообщений – подпись и шифрование XML сообщений
• Стандарты
• XML W3C Encription / Signature – подпись и шифрование фрагментов XML
документов
• WS-Security - поддерживает безопасность протокола SOAP,
конфиденциальность и целостность сервисов; согласован с другими
средствами авторизации подтверждения, такими как сертификаты X.509,
Kerberos и SAML
 • Security Assertion Markup Language (SAML) – служит для обмена
подтверждениями об аутентификации и авторизации между доменами,
поддержка SSO, уточнение - Liberty Alliance 1.0
• XML Access Control Markup Language (XACML) - язык разметки
управления доступом, является расширением XML для создания
конструкций, служащих для автоматизации авторизации и управления
доступом к информации. Средства XACML определяют те директивы,
которые формируются и передаются для управления доступом
• XML Key Management Service (XKMS) - служит стандартом для
инфраструктуры открытых ключей XKISS (XML Key Information Service
Specification) и регистрационной спецификации XKRSS (XML Key
Registration Service Specification).
• XML Service Provisioning Markup Language (XSPM) - средство описания
вспомогательных данных, необходимых для установления отношений между
сервисами
• Extensible Rights Management Language (XeML) - язык управления правами
собственности в мультимедиа, порожден движением Digital Rights
Management и в какой-то мере составляет конкуренцию языку XACML
• XML Common Biometric Forman (XCBF) – средство работы с
биометрическими токенами
• Интеграция с EIS и другими внешними ресурсами
• J2EE Connectors (JCA)
• На основе системного контракта с коннектором в числе прочего предполагает
предоставление сервисов безопасности
• Идентификация, аутентификация и авторизация пользователя
• Безопасная передача данных между сервером приложений и EIS,
использование специализированных протоколов типа Kerberos
• Использование специфических для вендора EIS расширений механизма
безопасности
• Коннектор работает через адаптер ресурса, в процессе создания Connection
осуществляющий безопасное соединение с EIS нативными средствами,
установленная идентичность клиента впоследствии подмешивается во все
запросы, выполняемых посредством предоставленной ему сессии
• Два режима идентификации, определяются через resource-ref/res-auth
• Контейнерный – контейнер логинится посредством адаптера ресурса в
EIS, а затем маппит своих пользователей на пользователей EIS.
Конфигурирует это все Deployer за счет определения свойств фабрики
соединений.
• Компонентный – компонент, получающий соединение, логинится
отдельно за счет методов фабрики соединений, указывая точный
логин/пароль. За счет использования resource-ref / res-sharing можно
указать возможность компонент передавать соединение другим
компонентам.
• Java Message Service (JMS) – рамочное API предоставляет возможность для
поддержания средствами провайдера
• Аутентификации при обращении к провайдеру сервера и осуществление
контроля доступа на основе логина / пароля
• Разграничение доступа на уровне использования отдельных очередей /
топиков. Не обязательная, настраивается средствами вендора, как правило на
основе ACL
• Безопасность на уровне сообщений и транспорта. JMS не предоставляет
возможности выбора транспорта, поэтому конфигурирование осуществляется
на основе свойств конкретного провайдера
 • Java Database Connectivity (JDBC)
• Начиная с JDBC 3.0 данная технология совместима с JCA со всеми
вытекающими возможностями.
• Стандартная возможность – осуществление аутентификации при создании
сессии на основе логина / пароля. Дальнейшее зависит от локальных свойств
драйвера и самой базы
• Опциональные возможности, предоставляемые вендорами
• Защищенный канал на основе SSL/TLS
• Шифрование и контроль целостности передаваемых данных
• Поддержка обращения через firewall
• Аудит выполняемых действий пользователя
• Сетевая топология
• Основной вопрос при выборе сетевой топологии – одиночные запросы /
использование сессией (stateless / stateful transactions ). Во втором случае
необходимо дополнительно обеспечивать
• Отказоустойчивость сессии
• Защиту механизмов трекинга сессии
• Балансировку загрузки
• Возможные опции
• Разделение ресурсов на статические (статический веб контент) и динамические
• Разделение слоев веб, бизнес и интеграции между собой файрволами.
• Более безопасно, но потери производительности и увеличение цены
обслуживания
• Недопустимо на пути интенсивного трафика, например между сервером
приложений и СУБД
• Защита от сбоев отдельных серверов и систем
• Failover – прозрачная переброска пользовательского запроса от мертвого
сервера к живому. В общем случае любое увеличение числа сервером
увеличивает цену обслуживания
• fault-tolerance – изоляция приложений от сбойных запросов без применения
параллельных серверов
• Изоляция веб сервера от веб-приложения – reverse-proxy. Получает запрос от
клиента и для его обработки создает отдельное соединение к тому же серверу, но
к порту, обслуживаемому приложением. Статические ресурсы отдаются как есть.

Шаблоны безопасности
общие шаблоны
• Локализация затрагивает

Веб слой
• Authentication enforcer – входная точка аутентификации
• Проблема - много входных точек обработки запросов, код идентификации /
аутентификации оказывается дублированным и размазанным по компонентам
системы, прикладные разработчики могут допустить брешь в каждой очередной
входной точке
• Требуется - чтобы механизм был централизованным, абстрактным, изолированным
от специфики протоколов, уровней системы и бизнес логики, не сцеплялся с
компонентами системы
• Решение
 • единый компонент, через который проходят все запросы ко всем входным
точкам системы.
• Использует подключаемый Security Provider как вспомогательный класс.
• Специфицирован общим интерфейсом, не связанным со спецификой какого-то
отдельного протокола.
• Пример реализации шаблона MVC. Применим в любом слое приложения
• Составляющие
• Authentication enforcer – входная точка доступа
• Получает управление от FrontController или ApplicationController, в
качестве параметра передается Request context
• выполняет аутентификацию клиента, используя предоставляемые им учетные
данные, выбранные из контекста, при помощи провайдера безопасности
• на основании выполненной аутентификации создает экземпляр Subject,
представляющий пользователя, кэшируется для обработки последующих
запросов от того же пользователя в данной сессии и снижения нагрузки на
провайдер безопасности
• Request context – контекст запроса
• доставляет входной точке учетные данные пользователя, выделенные из
запроса, защищая ее от специфики контекста.
• Переносит созданного Subject вдоль цепочки обработки запроса,
предоставляя остальному коду методы выяснения его идентичности,
используемых ролей и доступных привилегий
• Subject – представление аутентифицированного пользователя в системе,
содержит коллекцию Principals, которые в свою очередь набиты привилегиями
• Стратегии реализации
• за счет контейнера – используется по умолчанию в веб приложениях и ничего
не требует от разработчиков кроме декларативной настройки. Самый надежный,
но наименее гибкий вариант.
• за счет произвольного провайдера, самостоятельно подключаемого,
абстрагирующего сервис аутентификации третьего производителя.
• за счет JAAS – использование сконфигурированной для приложения коллекции
Login Modules, каждый из которых абстрагирует сервис авторизации. Большая
гибкость контроля над процессом в целом чем в J2EE, меньше собственного
потенциально ненадежного прикладного кода.
• Любой JAAS клиент использует данный шаблон. Вообще данный вариант
представляется наиболее стандартным
• последствия
• снижение количества кода, выделенного в единый повторно используемый,
потенциально высоко надежный компонент.
• Детали реализации сокрыты от остального приложения, защищены от изменений
и неправильного использования.
• Единая стратегия и реализация процесса авторизация для всех слоев системы
• Факторы и риски
• Если не полагаться на контейнер, то все-таки некоторое количество кода для
активизации процесса разработчики должны написать – потенциальная дырка
• Веб приложение потенциально очень уязвимо в части данного процесса
• Важен выбор метода авторизации. Наиболее надежный метод –
использование клиентского и серверного сертификатов, наименее
HTTP/BASIC авторизация на незащищенном канале
• Все значимые данные пользователя, имеющие отношение к процессу,
должны передаваться через защищенный канал
• Связанные шаблоны – ContextObject, Intercepting Filter
• Authorization Enforcer – входная точка авторизации
• Проблема – во многих точках системы требуется проверка того, что
авторизованный пользователь имеет определенный уровень доступа, право на
выполнение каких-то операций, доступ к какому-то ресурсу. В случае, когда
контроль не может быть возложен на контейнер, отвечающий за авторизацию, код
оказывается размазанным по системе и потенциально ненадежным
• требуется
• минимизировать сцепление между кодом авторизации и прикладным кодом
• Минимизировать сцепление между кодом авторизации и аутентификации, чтобы
два процесса могли эволюционировать независимо
• Логика авторизации должна быть централизованной и сокрытой от остального
приложения
• для веб приложения требуется контроль на уровне отдельных URL
• решение – единая точка доступа для разграничения доступа к веб ресурсам на
основе их URL. Через нее проходят все вызовы от SecureBaseAction,
абстрагирующей операции пользователя, требующие разграничения доступа.
• Составляющие
• SecureBaseAction – абстракция операции пользователя, берет Subject из
RequestContext и при помощи AuthrozationEnforcer проверяет его права на
выполнение операции
• RequestContext – предоставление запроса клиента в абстрагированном от
протоколе доступа виде. Переносит данные уже аутентифицированного
пользователя вдоль цепочки обработки запроса в виде Subject
• AuthrozationEnforcer – входная точка осуществления авторизации
• использует AuthorizationProvider для получения на основании Subject
объекта PermissionCollection.
• Кэширует коллекцию разрешений в Subject и использует в дальнейшем для
разрешения / запрещения доступа к конкретному URL на основании его
анализа
• Стратегии реализации
• За счет контейнера
• используется по умолчанию в веб приложениях и ничего не требует от
разработчиков кроме декларативной настройки. Самый надежный, но
наименее гибкий вариант.
• Основной недостаток – статичность настройки. Роли фактически
реализованы как привилегии, что снижает возможность гибкой настройки
доступа пользователя – ролей нет, на уровне администрирования фактически
приходится манипулировать привилегиями ресурсов
• Доступ не может быть разграничен на основании свойств ресурса и данных
пользователя
• За счет самостоятельно подключаемого провайдера, который возвращает
коллекцию разрешений
• Программная авторизация
• разрешения создаются в момент возникновения ресурса и перестраиваются в
процессе его жизни, ACL
• наиболее гибкая, но потенциально подверженная пробелам в реализации
• Авторизация на основе JAAS
• Наиболее стандартный путь
• Тоже используется декларативный маппинг разрешений на ресурсы,
оптимален для систем, которым не требуется динамическое создание
защищаемых ресурсов
 • Последствия - централизация контроля, избежание дублирование кода, изоляция
его от специфики системы, протоколов, механизма авторизации и т.д.
• Факторы и риски
• Основные вопросы – насколько гранулярной должен быть контроль доступа,
• слишком малое число ролей приводит, например, к тому, что пользователю
для выполнения бизнес функции приходится на какое-то время выдавать
права админа. Или он получает права на большее количество объектов, чем
ему надо в рамках его ответственности.
• Вопрос тесно связан с бизнес спецификой приложения и выявленными
прикладными прецедентами использования
• необходимость динамической перестройки доступа к ресурсам, создания новых
защищаемых ресурсов – приводит к существенному возрастанию сложности
системы и потенциальным дырам
• связанные шаблоны – Context Object, Authentication Enforcer
• Intercepting Validator – перехватывающий контроль запросов
• Проблема – необходимость простого и гибкого механизма анализа данных запросов
от клиента на наличие вредоносного кода или данных, приводящих к сбоям в
системе. Данные могут быть представлены в любых видах – формы, URL запросы,
XML документы и т.д.
• Требуется
• Поддержка расширяемого перечня проверяемых форматов данных и наборов
проверок, гибкая настройка логики проверок
• Разделение механизма проверок и остального презентационного уровня
• Решение
• единая точка доступа к сервису проверки запросов, конфигурируемая
перестраиваемым списком фильтров
• фильтры завязаны на шаблоны проверяемых URL и конкретные форматы /
логику проверки. НЕ выполняют обработку данных, только проверку в отличие
от шаблона Intercepting Filter
• вызывается максимально рано в цепочке обработки пользовательского запроса, в
отличие от Intercepting Filter его конфигурация значительно более стабильна и
потому может задаваться декларативно
• Связь с клиентскими проверками
• Клиентские проверки ВСЕГДА и принципиально ненадежны, поэтому
серверная проверка обязательна.
• Клиентская проверка ближе к пользователю, удобнее, более интерактивна,
позволяет экономить серверные ресурсы, поэтому она необходима, но не
достаточна
• Серверные проверки имеют более широкую функциональность, легче
настраиваются, стоимость реализации ниже
• Составляющие
• SecureBaseAction – абстрактное представление действия пользователя,
существенного с точки зрения безопасности.
• Проверяет данные, переданные пользователем при помощи
InterceptingValidator
• Если проверка прошла – вызывает реализацию запрошенной операции в
виде Target
• InterceptingValidator – единая входная точка сервиса проверки данных
запроса
• принимает управление от SecureBaseAction
• хранит список конкретных валидаторов в виде Validator
• получив от SecureBaseAction запрос прогоняет его через все Validator
 • Validator – абстракция проверки данных запроса
• конфигурируется через шаблон URL, формат анализируемых данных,
логику проверки.
• Конкретные реализации – ParamValidator, SQLValidator и т.д. Части
используются обобщенные проверки на основе регулярных выражений
• Target – реализация определенной бизнес операции или представление
ресурса, принимает проверенный запрос от SecureBaseAction
• Последствия
• Централизованное решение, все возможные атаки через данные запроса
обрабатываются стандартным образом
• Логика проверки отделена от бизнес логики, легко перестраивается и
расширяется за счет новых валидаторов, отделена от протокола взаимодействия с
клиентом
• Возможно добавление проверок не связанных напрямую с данными пользователя
– опциональный таймаут сессии, перечень разрешенных IP, защита от DoS атак
и так далее
• Логика проверки абстрактна и не может учитывать специфику защищаемых
ресурсов и свойств пользователя.
• Факторы и риски
• попытка обработать все возможные типы атак подобного рода приведет к
значительному снижению производительности. Необходима выработка
компромиссов
• код валидаторов чувствителен к атакам на переполнение буфера
• связанные шаблоны – Intercepting Filter, Message Inspector
• Secure Base Action – абстракция защищаемого действия пользователя
• Проблема – необходимость централизованной реализации целостной логики
обработки пользовательских запросов с точки зрения безопасности.
• Требуется
• Собрать воедино логику и реализацию всех операций, связанных с безопасной
обработкой пользовательских запросов
• Изолировать код безопасности от прикладного кода, обеспечить возможность
независимого развития
• Обеспечить простоту и прозрачность механизма с точки зрения прикладного
кода
• Решение - единый компонент, координирующий все действия, связанный с
безопасностью, предоставляющий веб слою единую точку доступа к сервису
безопасности
• Составляющие
• SecureBaseAction – абстракция защищаемого действия пользователя,
• последовательно вызывает для запроса все основные сервисы безопасности в
соответствии с зашитой логикой
• разрабатывается специальными разработчиками и затем используется
прикладными без необходимости знания специфики реализации либо за счет
наследования, либо посредством шаблона Command
• AuthenticationEnforcer, AuthorizationInforcer, SecureLogger,
SesureSessionManager, InterceptingValidator – отдельные сервисы, связанные с
безопасностью: аутентификация, авторизация, ведение безопасного лога, трекинг
сессии, проверка данных запроса
• Target – реализация действия, запрашиваемого пользователем, которому после
выполнения всех действия и проверок SecureBaseAction передает управление
• Последствия
 • Упрощается реализаций требований безопасности и в целом управление
аспектом.
• Единая точка интеграции между уровнем представления и сервисом
безопасности. Внесение изменений в подсистему безопасности не влияет на
остальное приложение
• Увеличивается вероятность повторного использования кода, вследствие этого
снижается цена и увеличивается надежность.
• Весь код, имеющий отношение к безопасности может быть развернут отдельно в
подписанном виде, гарантирующем его целостность
• Факторы и риски
• Пониженная гибкость решения, полностью изолирующего прикладной код од
деталей, связанных с безопасностью. Большие проблемы, если потребуется для
какого-то действия специальным образом реализовывать один из базовых
сервисов
• Связанные шаблоны – FrontController, Command
• Security Logger – безопасное ведение лога
• Проблема – все события приложения вместе с идентифицирующими данными
должны быть отражены в логе и безопасно хранится для отладки, обнаружения /
предупреждения атак, последующих судебных разборок
• Данные после занесения должны быть Read-only, защищены от изменения /
стирания, а также от внешнего доступа на чтение администратором /
пользователем не имеющим прав
• Код, выполняющий логирование, сложен, поэтому должен быть централизован,
защищен, отделен от прикладного кода, повторно используем во многих
приложения для снижения стоимости и увеличения надежности
• Требуется
• Обеспечение целостности и конфиденциальности данных лога, причем как на
уровне отдельных записей, так и на уровне лога в целом (защита от стирания
записей)
• Возможность настройки степени подробности и степени защиты лога для
операций различной степени важности
• Обеспечение централизованного контроля над процессом логирования
• Возможность использования криптографических механизмов зажиты данных и
контроля целостности лога
• Гибкость настройки форматов и расположения хранилище данных, в которых в
конечном итоге попадают сообщения
• Решение – единый компонент, изолирующий прикладной код от подробностей
реализации подсистемой необходимых требований
• Составляющие
• SecureLogger – единая входная точка процесса
• принимает от клиента сообщения и реализует общую логику их обработки, в
частности опциональную генерацию последовательного уникального ИД
события для контроля целостности лога в целом
• Опционально может выполнять шифрование / подпись данных в целях их
защиты, если это не может быть возложено на хранилище
• передает LogManager для записи в лог
• LogManager – единая точка доступа ко всем хранилищам
• запрашивает от LogFactory определенную реализацию Logger в
зависимости от свойств сообщения и заданных SecureLogger опций
• передает сообщение Logger для записи в хранилище
• LogFactory – фабрика создания Logger исходя из декларативно определенной
его конфигурации, кэширует коллекцию созданных Logger
 • Logger – сконфигурированный агент формирования записи о событии в
определенном хранилище.
• Стратегии
• Secure Data Logger – обеспечение безопасности данных за счет самого логгера
• Используется, когда задачу контроля целостности лога нельзя возложить на
инфраструктуру
• В число составляющих шаблона добавляются сервисы обеспечивающие
шифрование / подпись сообщения
• Так как ведение лога должно осуществляться быстро, то требуется
использовать симметричное шифрование. Возникает требование защиты
ключа, поэтому задача шифрования выносится в отдельный компонент
EncryptionHelper.
• В составе приложения НЕ должно быть средств, обеспечивающих
возможность дешифрования информации лога. Надо делать отдельной
утилитой, доступной только админам и защищаемой системными средствами
• Высокая вычислительная нагрузка на приложение – за счет ведения лога
может тормозиться выполнение бизнес функций
• Secure Log Store – обеспечение безопасности данных за счет хранилища
• Данные в процессе передачи хранилищу необходимо защищать за счет
SecurePipe
• В отличии от предыдущего случая меньше грузит само приложение, так
как оно теперь не выполняет шифрование / подпись, а SSL канал требует
менее вычислительных ресурсов
• Хранилище не должно позволять приложения выполнять обновление /
удаление занесенных данных, а также неавторизованное создание новых
записей
• Последствия
• Централизация контроля и управления, минимизация риска неправильного
выполнения прикладным кодом
• Расширяемость за счет прозрачной для приложения перестройки механизмов и
стратегий логирования
• Всегда можно динамически установить уровень компромисса между
требованиями безопасности и вычислительной нагрузкой на приложение
• Факторы и риски
• Основной риск – управление ключами, особенно существенен из-за
необходимости симметричного шифрования
• Поддержка конфиденциальности и целостности данных как при передаче, так и
при хранении
• Зачастую защита лога может быть осуществлена только системными средствами
или только малую часть лога надо защищать столь свирепо. Зависит от бизнес
специфики приложения
• Связанные шаблоны – Abstract Factory, Secure Pipe, UUID
• Secure Pipe – безопасный канал передачи данных
• Проблема – необходимость обеспечить безопасный канал передачи данных в
небезопасной среде, обеспечить конфиденциальность / целостность, исключить
атаки «man-in-the-middle», replay, spoofing и т.д.
• Требуется
• Изолировать прикладной уровень приложения от необходимости думать о
безопасности данных, возложить задачу на инфраструктуру
• Обеспечить возможность
• вынести вычислительную нагрузку на специализированные устройства
• использования специализированных решений третьей стороны
 • ограничить объем защищаемых данных в соответствии с их важностью, чтобы
избежать вычислительной перегрузки
• Решение
• Сервис приема / передачи данных приложением / клиентом реализуется единой
входной точкой, защищающей прикладной код от специфики реализации
процесса. В случае необходимости, реализация сервиса может использовать
аппаратные ускорители ресурсоемких операций
• Составляющие
• Client - инициирует диалог, выполняя логин в приложении, договаривается с
предложенным приложением SecurePipe, устанавливая защищенные
соединение, отправляет в соединение запросы, в том числе финальный – logout
на завершение взаимодействия
• Application - за счет инфраструктуры создает SecurePipe, которое путем диалога
устанавливает с клиентом защищенное соединение. Принимает от SecurePipe
запросы клиента и их выполняет, по финальному logout запросу уничтожает
SecurePipe. Представлена двумя компонентами – клиентской и серверной
сторонами, могут быть как библиотеками, так и аппаратными компонентами
• SecurePipe - за счет договора с клиентом устанавливает и поддерживает
защищенное соединение, принимает от него запросы и отдает приложению
• Стратегии
• Соединение с веб сервером на основе SSL/TLS. Перед использованием сервер
должен быть подготовлен - очищен от лишних компонент, удалены пароли /
сертификаты по умолчанию, установлены патчи и т.д.
• Специализированное серверное железо, осуществляющее аппаратную
реализацию SSL, избавляет веб сервер от излишней нагрузки
• Сетевое устройство, стоит перед веб сервером и упаковывает его трафик в
закрытый канал, может поддерживать несколько веб серверов, одновременно
выполнять задачи по балансировке трафика и т.д.
• Самостоятельная реализация на основе JCE
• Последствия
• Канал полностью защищен, совместим с программными и аппаратными
платформами
• При использовании аппаратных средств нагрузка на приложение возрастает
незначительно
• Факторы и риски
• Настройка инфраструктуры, особое внимание на защищенность конфигурации.
Аппаратные решения более защищены
• Вычислительная нагрузка, возможно, что не все данные надо гнать
защищенными. Например, защищать только процедуру аутентификации
• Управление сертификатами
• Связанные шаблоны – Point-to-Point-Channel, но он только осуществляет доставку,
не защищая содержимое
• Secure Service Proxy – защита прикладного сервиса посредством прокси
• Проблема – адаптировать уже существующее незащищенное или слабо защищенное
приложение к новому протоколу, обеспечивающему безопасность взаимодействия с
пользователем
• Требуется
• Возможность адаптации уже имеющегося приложения, в частности веб или веб
сервиса, без необходимости переписывания
• Полностью разделить прикладной код и код, обеспечивающий защиту
передаваемых данных
 • Возможность легкой интеграции приложения со средством стороннего
производителя, позволяющая снизить риск и стоимость
• Возможность поддержки нескольких протоколов доступа
• Решение
• Выполнение задач аутентификации / авторизации выносится на отдельный
компонент, перехватывающий все запросы пользователя, анализирующий и
выполняющий от своего имени. Данный компонент выполняет все задачи,
связанные с формирование контекста безопасности, поддержки сессии и т.д.
• Также компонент выполняет трансформацию запросов / ответов между внешним
защищенным протоколом и внутренним протоколом, понятным защищаемому
приложению
• По принципу работы аналог Web Agent, но производится не только ограничение
доступа по URL, но и полное переформирование запросов / ответов
• Составляющие
• SecureServiceProxy – перехватывает запросы пользователя, при помощи
SecurityProtocolHandler разбирает запросы, выполняет авторизацию запросов,
преобразует данные запроса, от своего имени запрашивает приложение,
преобразует данные ответа, возвращает ответ пользователю
• SecurityProtocolHandler – поддержка отдельного протокола безопасности, в
частности выполнение аутентификации средствами, предусмотренными
спецификой протокола
• Стратегии
• Может представлять один сервис
• выполнять роль координатора сервисов – фасада системы, роутера с
сохранением состояния
• ограничивающего выставляемые методы и изменяющего гранулярность
методов
• поддерживающего единый контекст безопасности и транзакционный
контекст, координирующего внутренние запросы между сервисами
• транслирующий протоколы всех задействованных систем друг в друга и в
защищенный протокол клиента
• так как клиент не видит внутреннюю кухню, то существенно сокращается
риск дырок в защите
• Последствия
• Возможность реализации application specific firewall, дополнительные фичи в
виде сокрытия реальных адресов сервисов, ограничения числа запросов,
контроль качества сервиса
• Возможность легкой адаптации к различным реализациям безопасности, в
частности не-J2EE приложений к J2EE инфраструктуре безопасности
• Увеличение производительности, так как на SecureServiceProxy может быть
возложена обязанность проверки данных запросов, а также нагрузка связанная с
криптографией
• Факторы и риски
• идентификация сервиса и контроль формата запросов
• в ряде случаев функциональность лишняя, можно обойтись веб агентом.
• Данный шаблон применяется ТОЛЬКО для адаптации старого приложения к
новому протоколу или средству защиты
• Связанные шаблоны – Proxy, Intercepting Web Agent, Secure Message Router, Extract
Adapter
• Intercepting Web Agent – защита веб приложения агентом
• Проблема – надеть аутентификацию и авторизацию «сверху» на готовое веб
приложение
 • Требуется
• не модифицировать код приложения и не возлагать на него дополнительную
вычислительную нагрузку
• разделить задачи безопасности и прикладные, обеспечить возможность
настройки безопасности только за счет изменения конфигурации средств защиты
• обеспечить возможность применения средств безопасности сторонних
производителей, вместо того, чтобы разрабатывать собственные
• Решение
• Все функции аутентификации и авторизации выносятся в один проксирующий
компонент, которые выполняет перехват запросов клиента к веб приложению.
Располагается на самом веб сервере или между веб сервером и приложением
• Хранение данных и выполнение самого процесса аутентификации / авторизации
может выноситься на отдельные сервера
• Составляющие
• WebServer – получает запрос клиента к приложению (первый или очередной в
сессии), передает его для анализа агенту
• Intercepting Web Agent
• Выполняет аутентификацию клиента, данные / функционал процесса
аутентификации могут быть как в составе самого агента, так и вынесены на
отдельный сервер
• Сохраняет данные аутентификации в зашифрованные куки сессии. В
дальнейшем использует куки для опознания уже аутентифицированного
клиента и получения его ИД
• Выполняет авторизацию запроса пользователя по определенному URL на
основании установленной идентичности. В случае успешности – отдает
запрос приложению
• Стратегии
• External Policy Server – данные для идентификации / авторизации могут
храниться отдельно, на специализированном сервере
• Можно обслуживать несколько веб серверов / агентов
• Веб сервер обычно находится в DMZ, что не способствует защите данных.
Соединяться с сервером политики надо через защищенный канал
• Полученные от Policy Server данные можно кэшировать в агенте для
производительности
• Последствия
• Возможность внедрения развитых продуктов третьих фирм, предупреждающих
большое количество известных атак
• Большая гибкость архитектуры, независимое развитие, отсутствие завязки на
конкретные продукты
• Горизонтальная масштабируемость безопасности, затраты не влияют на
производительность приложения
• Факторы и риски
• Веб сервер должен быть безопасным, чтоб предотвратить отключение агента
• Авторизация не работает, когда операции / ресурсы в приложении не
сопоставлены с URL. Тогда требуется разбор параметров, что делают не все
продукты. В целом данные шаблон предоставляет слишком крупно
гранулированный контроль
• Связанные шаблоны – Secure Service Proxy, Proxy, Message Interceptor Gateway
• Дополнительные советы
• веб сервер - в ДМЗ, запускать из-под ограниченного пользователя, запретить CGI,
фильтровать на НТТР пакеты, все админские работы на сервере через SSL канал,
установить политику смены и контроля пароля, запретить исходящие соединения
 наружу, мониторить устанавливаемые соединения, все существенные данные
вынести из ДМЗ, получать из через защищенный канал, тактика «горшка с медом»
• потоки данных – запрет не-SSL запросов после установления SSL соединения,
мониторить «плохие» SSL запросы, сервер-сервер защищать на основе
сертификатов, контроль валидности сертификатов
• приложения – должны проверять, что получают запрос с веб сервера, запретить им
обращаться к веб серверу, конфигурационные свойства шифровать или
подписывать, администратор в приложении не должен мапиться на системного
админа или админа в базе данных, идентичность пользователя должна сохраняться
до самого конца обработки запроса, в том числе при работе с базой, контроль
целостности сессии, аудит всех задач

Бизнес слой
• Особенности
• Отсутствует стандартная модель осуществления аудита операций
• Много используемых средств третьих производителей – потенциальные дыры
• Нет модели безопасности, основанной на передаваемых данных
• Audit Interceptor – средство осуществления аудита
• Проблема – перехват и аудирование запросов к бизнес слою и результатов их
обработки.
• Лог аудита должен периодически тестироваться на предмет выявления
неправомочных действий пользователя. На основании должны либо фиксится
багги, либо изменяться политика доступа.
• Проблема в том, что перечень аудируемых действий плывет, а системные
события им соответствующие зачастую не известны до реализации приложения.
• Не предотвращает текущую атаку, но может дать информацию по ходу атаки /
падения системы для предотвращения будущей
• Требуется
• Централизованное декларативное определение логики перехвата и обработки
запросов / ответов / исключений, трансляции параметров событий
• Разделение кода аудирования и прикладных сервисов
• Решение
• Все запросы к сервисам пропускаются через единое входное горло,
обеспечивающее перехват, пост и пред обработку
• Логика трансляции потока регистрируемых событий в события лога
определяется декларативно, отдельно от интерцептора
• Составляющие
• AuditIntercepter – единая входная точка
• принимает сообщения, чаще всего от SessionFasade и отдает их конечному
сервису. К записи в аудит приводят только входные запросы пользователя,
дальнейшие операции по их обработке в аудит не попадают, только в логи
• Варианты работы – перехватываем только запросы (попытки), только ответы
(удавшиеся попытки), исключения (ошибки) или все
• Хорошо использовать AOP
• EventCatalog – конфигурационная база данных для трансляции,
• AuditLog – абстракция сохранения потока событий в файл, БД, очередь
сообщений и т.д.
• Должен быть только для чтения, лучше на отдельной защищенной машине
• Не должен замедлять приложение за счет времени регистрации событий,
важна масштабируемость. Хорошо использовать постоянную очередь JMS
• Последствия
• Способствует гибкости, легкости настройки политики аудита, обслуживаемости.
 • Снижает производительность
• Не нужно перестраивать код формирования аудита внутри прикладного при
изменении политики безопасности – меньше стоимость, быстрее реализация
• Container Manager Security – использование контейнера безопасности
• Проблема – хочется внедрить в J2EE приложение аутентификацию и авторизацию
без необходимости написания специализированного кода. Альтернатива –
использование JAAS и программного подхода
• Требование
• Средство декларативного определения и реализации статической модели
безопасности
• Не дать разработчикам возможности исказить политику безопасности
• Стратегии
• Только в веб-контейнере
• если прикладные сервисы не могут быть впрямую вызваны клиентом или
вызываются через SecurutyServiceProxy / SecurityServiceFasade
• структура URL должна соответствовать структуре разграничения доступа.
Зачастую у приложения единый входной URL с параметрами
• Только в EJB контейнере – на уровне бинов или методов бинов
• Использование вспомогательных библиотек может приводить к нарушению
модели безопасности
• В обоих
• Последствия
• модель безопасности статическая, решение не может быть принято на основании
свойств объекта, пользователя, времени суток и т.д. Слегка лечит прикладное
API контейнера, но сведений о принципале слишком мало
• состав привилегий для роли фиксирован и не может быть изменен без
пересборки и развертывания. Вследствие чего роли вырождаются в привилегии и
работа администратора затрудняется
• Контейнер – хорошо тестированное решение, меньше риск дырок в
инфраструктуре
• Dynamic Service management – динамическое управление сервисами
• Проблема – возможность вручную управлять множеством POJO компонент,
которые, например, осуществляют мониторинг / защиту приложения. Быстрое
изменение параметров необходимо для обнаружения / прекращения атаки.
• Требования
• Управление POJO объектами, которые не поддерживаются контейнером в
реальном режиме времени
• Использование для доступа к компонентам стандартного протокола JMX. Клиент
запрашивает доступ к сервису по имени, сервис реализуется как MBean и
выставляется клиенту по JMX
• Решение
• Выделение управления этими объектами в отдельный сервис – менеджер
сервисов
• Составляющие
• ServiceManager – создает экземпляр MBeanServer для регистрации будущих
созданных экземпляров бинов и MBeanFactory для их создания. Созданные
MBean регистрирует в MBeanServer под ИД для доступа клиента
• MBeanServer – выставляет зарегистрированные MBean по протоколу JMX для
клиента
• MBeanFactory – создает MBeanFactory, считывает оттуда метаданные бинов по
ИД, создает экземпляры Подписана на события RegistryMonitor для
пересоздания бинов на основе факта изменения конфигурации в хранилище
 • Registry – реестр описаний бинов, загружает метаданные из DescriptionStore,
кэширует и предоставляет MBeanFactory. Создает RegistryMonitor для
наблюдения за хранилищем и перезагрузке измененных конфигураций
• RegistryMonitor – наблюдает за хранилищем, оповещает слушателей об
изменениях
• DescriptionStore – хранилище конфигурационных данных для бинов
• Стратегии
• Обычно JMX бины создаются исходя из программно определяемого бина
модели, но можно использовать Jakarta Commons-Modeler для создания модели
из XML описания. Предоставляет реализацию Registry и DTD грамматику XML
файлов.
• Последствия
• Избавляет от необходимости анализа и проектирования интерфейса управления
всеми вспомогательными системными компонентами, которых может быть
несколько сотен
• Позволяет в реальном времени менять уровень безопасности и нагрузку на
систему
• Факторы и риски
• При доступе к бинам необходима идентификация / авторизация, лучше
защищенный канал, так как их свойства могут быть секретными
• Управляемые свойства бинов должны быть элементарных типов, чтобы
отображаться в интерфейсе редактирования
• Obfuscated Transfer Object – защищенный транспортный объект
• Проблема – критические для приложения данные в процессе передаче по цепочке
вызова внутри и между слоями может быть напечатаны, выброшены в лог или как
еще раскрыты третьими компонентами, которые в принципе не должны иметь к ним
доступ. Возможности вычистить код этих компонент, зачастую нет, поэтому задача
защиты данных возлагается на объект перевозчик
• Требования
• Защита критических данных при передаче по цепочке вызова из не-доверенных
компонент
• Возможность гибкого управления тем, какие данные объекта признаются
критическими
• Решение – ответственность за разделение и защиту данных возлагается на объект
перевозчик. Приложению для работы с данными предоставляется обобщенный
интерфейс на основе пар имя-значение
• Стратегии
• Masked List – в объекте два списка, один для защищенных данных, другой для
простых. Кроме того перечень наименований, значения которых должны
защищаться.
• Данные в защищенным списке хранятся маскированными и в сериализации
не участвуют, в toString() тоже
• Недостаток – промежуточный компонент может явно запросить данные и их
напечатать
• Exncryption – на период передачи закрытые данные шифруются симметричным
для скорости ключом
• Недостаток – сложно скрыть ключ от промежуточных компонент, если все в
одном слое
• J2SE предоставляет специализированное средство – Sealed Object
• Последствия
• Хорошая защита против прослушивания и атаки на лог файл
• Централизация кода по защите и отделение от прикладного кода
 • Для больших объемов данных – замедление выполнения, поэтому надо
тщательно отбирать защищаемые данные. Можно настраивать через метаданные
прозрачно для использующего объект кода
• Подходит для систем обмена сообщениями и распределения сессионной
информации между узлами приложения
• Policy Delegate – делегат реализации политики в составе клиента
• Проблема – требуется изолировать клиента от поиска сервисов и подробностей
того, как их вызвать, с использованием текущей инфраструктуры безопасности.
• Требуется
• Уменьшить связность между кодом клиентским и безопасностью, изолировать
клиента от интерфейсов инфраструктуры безопасности
• Управление ЖЦ клиентским контекстом безопасности, создание его с нуля для
каждого запроса – тяжелая задача
• Централизовать выполнение функций, связанных с безопасностью
• Решение
• Запросы к сервисам должны проходит через единую точку, реализующую
подмножество функций, необходимых клиенту и концентрирующую работу с
безопасностью – аутентификация, авторизация, логирование, проверка
параметров, конфиденциальность передаваемых данных за счет транспорта или
использования защищенного транспортного объекта
• аналог SecureBaseAction для веб слоя, как правило, на серверной стороне будет
Secure Service Façade
• Также защищает клиента от изменения интерфейсов сервисов, выполняет
трансляцию форматов сообщений, преобразует транспортные / безопасности
исключения в прикладные
• Может быть stateless и statefull, последний кэширует контекст безопасности за
счет объекта с PoliceDelegate идентификационными данными. На стороне
сервера ему соответствует полноценная сессия, что способствует оптимизации
нагрузки за счет повторного использования объектов
• Составляющие
• PoliceDelegate – может смотреть на несколько сервисов, выбирая только
необходимые функции. В пределе может быть фабрикой получения интерфейсов
по ИД сервиса, скрывающей все остальные детали взаимодействия с ними. В
этом случае ссылки на сервисы загружаются Lazy по мере необходимости
• SecureSessionObject – клиентское описание сессии, хранящая установленные
идентификационные данные пользователя, а также ссылки на используемые им
сервисы
• Последствия
• Сокращает число сетевых вызовов за счет хранения установленной
идентичности пользователя для осуществления последующих бизнес вызовов.
Оптимизирует производительность
• Значительно снижает сложность использования сервисов для прикладного
разработчика
• Осуществляет защиту от сбоев и восстановление после них, может кэшировать
запрашиваемые справочные данные
• Если безопасность уже поддерживается на веб уровне, то можно обойтись
просто бизнес делегатом
• Иногда слишком разрастается, тогда надо делить на несколько или делать
фабрику суб-сервисов
• Secure Session Façade – защищенный сессионный фасад
• Проблема – необходимость иметь единую безопасную входную точку к набору
сервисов, унифицирующую применение политики безопасности и изолирующую
сервисы от необходимости иметь дело с данным аспектов
• Дополнительно – изменение гранулированности предоставляемого API, изоляция
клиента от необходимости реализовывать логики совместного использования
сервисов, ограничение пересылаемых на клиент данных до необходимого
минимума, изоляция его от многообразия моделей данных сервисов, поддержка
единого транзакционного контекста обработки клиентского запроса
• Каждый сервис может иметь свою систему безопасности и подходы к
аутентификации / авторизации, их совмещение клиентом может быть трудной
задачей
• Часть сервисов вообще ранее не были выставлены для удаленного использования
и нуждаются в защите, причем возможности изменить их код нет
• Опционально выполняет задачи логирования, проверки данных запросов на
предмет атак через параметры и т.д.
• Требования
• Вынесение ответственности в единую точку, уменьшение связывания с
прикладным кодом. Централизация логики защиты и администрирования
политик всех сервисов
• Поддержка единого контекста безопасности при последовательных операциях
клиента, передача его всем сервисам в ожидаемом для них виде
• Минимизация числа сообщений от клиента за счет обработки одного
клиентского запроса в виде последовательности вызовов различных сервисов с
хранением промежуточного состояния процесса обработки
• Решение – введение медиатора, являющегося единой безопасной точкой доступа к
множеству сервисов, унифицирующего их интерфейсы и реализующего логику их
совместного использования для обработки запроса клиента
• Составляющие
• Client – передает фасаду запрос, от простого, до дерева вызова с предикатами
модификации отдельных операции – шаблон Command
• Secure Session Façade – чаще всего реализуется как statefull бин или сервлет.
• Непосредственно обращается к независимым сервисам, ищет их при помощи
ServiceLocator или использует Dynamic Service Management.
• Сервисы могут вызываться параллельно для повышения производительности
• Сервисы могут быть на любой технологии, логика их вызова
концентрируется в фасаде
• Security Framework – инфраструктура безопасности
• Secure Session Object – хранение промежуточных бизнес данных, а также
данных безопасности, которые передаются каждому из сервисов при их вызовах.
• Стратегии реализации
• Фасад статически связанный с набором сервисов, выставляющий их методы как
есть или статически преобразую
• Фасад, позволяющий клиенту сформировать запрос по реализации произвольной
последовательности вызова сервисов.
• Возможны условные конструкции и правила передачи данных из одних
вызовов в другие, фактически мини программа. Может использоваться rule-
based engine
• Новые сервисы могут динамически подключаться / отключаться, вызываются
клиентом по ИД
• Последствия
• Защищает бизнес слой от атак сквозь веб слой или веб сервисы.
 • Обязателен, когда клиент прямо ходит в бизнес слой, при этом хорошо
сочетается с Policy Delegate
• Хороший выбор для выставления унаследованных систем для внешнего
использования
• Факторы и риски
• Может неконтролируемо разрастаться и терять управляемость,
• Нужен только когда необходимо агрегировать несколько сервисов или
организовать их сложное взаимодействие, иначе лучше Secure Service Proxy
• Secure Session Object – хранение и распространение контекста безопасности в
распределенной среде
• Проблема – реализация распределенного множества пользователей доступа к
сервисам системы
• передача контекста безопасности и клиентской сессии в совокупности
платформ / серверов
• способ компонентам установить факт того, что аутентификация / авторизация
клиента была выполнена успешно
• избавление клиента от необходимости заново проходить аутентификацию при
каждом новом запросе
• Требуется
• Реализовать структуру данных для хранения контекста безопасности в виде,
пригодном для проверки отдельными компонентами. Обеспечить ее безопасную
передачу между отдельными приложениями, серверами, компонентами, слоями
и т.д.
• Определить токен, который будет уникально идентифицировать контекст и
передаваться вместе с пользовательским запросом между компонентами. В
частности для реализации SSO
• Абстрагироваться от специфики реализации сессии отдельными вендорами
• Решение
• Использование специального объекта для хранения сведений о выполненных
аутентификации / авторизации, полученных от провайдера безопасности. К
этому относятся идентичности, выданные роли / привилегии, данные
используемые при защите транспорта
• Данные должны быть защищены от подмены, вывода недопустимой информации
в лог или при сериализации, исследования на уровне отражения и т.д.
• Составляющие
• SecureSessionObject – получается клиентом от системы при первом запросе и
подмешивается во все остальные. Хранит всю необходимую информацию.
Может быть проверен любым компонентом системы, получившим запрос
• Target – вызванный компонент, получает в составе запроса SecureSessionObject,
проверяет его целостность, использует данные в нем для авторизации запроса
• Стратегии
• Transfer Object Member – контекст передается как защищенная часть
транспортного объекта, позволяет не изменять имеющиеся бизнес интерфейсы
системы
• Interceptor – более применима в распределенной модели, у клиента и у сервера
есть по интерцептору, которые перехватывая запрос подмешивают / выделяют из
него сессионный объект.
• Также договариваются между собой о параметрах защиты канала
взаимодействия в целом или только самого объекта
• В этом случае объект может быть только на сервере, а у клиента только
идентифицирующий его токен – удаленная ссылка на объект. Минимизирует
трафик между клиентом и сервером
 • Позволяет абстрагироваться от реализации инфраструктуры безопасности,
так как и клиент и сервер не подозревают о защищенности канала. Слабое
связывание приложения с безопасностью
• Последствия
• Защищает от подмены сессии при атаке изнутри периметра безопасности,
возможном когда контекст не передается и следовательно не проверяется на
бизнес уровне
• Часто используется для связывания веб и бизнес слоя, может применяться
например при JMS обмене
• Позволяет абстрагироваться от используемой инфраструктуры безопасности и
даже прозрачно заменить ее на другую
• Снижает трафик и вычислительные затраты на периодическую ре-
аутентификацию и прочие процессы
• Факторы и риски
• в веб приложении можно хранить сессию на клиенте – недопустимо по причине
слабой защищенности при передаче и хранении. Только криптографически
защищенный токен и объект на сервере
• если объект передается при вызове целиком остро встает задача проверки
неизменности его данных
• слишком большой объект приводит к значительным расходам на сериализацию /
десериализацию
• к объекту как правило осуществляется конкурентный доступ, это надо учитывать
при проектировании
• Дополнительные советы
• Инфраструктура – JAR должны подписываться, чтобы вредоносный код не мог
развернуть собственные, доступ к JNDI на чтение должен разграничиваться для
приложений и быть запрещенным для записи, исключения системного уровня не
должны выводиться клиенту
• Архитектура - не должно быть глобальной роли «Администратор», которому
разрешено все, по возможности присваивание ролей пользователю должно быть
динамическое, в том числе и с удалением роли по таймеру, при использовании
декларативного маппинга надо избегать давать ролям приложения те же имена, что
и ролям / группам / пользователям окружения, пароль / логин не должны ходить по
сети открытыми, для толстого клиента надо использовать аутентификацию на месте
за счет клиентского контейнера
• Политика безопасности – удаление из системы неиспользуемых протоколов и
сервисов, доступ пользователей должен быть ограничен во времени, ограничения на
сложность и срок годности паролей, запрет долгих транзакций, компромисс между
строгость и ценой безопасности

Веб сервисы
• Особенности
• Основное отличие – разные части одного сообщения могут требовать разного
подхода к защите
• Три основных слоя безопасности
• Сетевой – защита периметра, хостов, портов, протоколов, отдельных сетевых
сервисов, ограничение соединений от недоверенных клиентов. Средства –
маршрутизаторы и файрволы
• Транспортный – обеспечение безопасной передачи данных между конечными
точками взаимодействия. Средство – HTTPS/SSL, VPN
 • Сообщений – специфические средства защиты данных, представленных в виде
XML документов. Защита от внедрения в XML вредоносного контента, проверка
валидености
• Типовая инфраструктура безопасности веб сервиса
• Защита периметра - файрволл / роутер / фильтрующий шлюз, обработка
входящих и исходящих пакетов, огранизация ДМЗ
• Внутри ДМЗ
• XML файрволл – прокси, обрабатывающий запросы на уровне анализа
содержимого XML – контроль синтаксиса, защита от переполнения, поиск
вирусов во вложениях, SQL/XQUERY запросы, попытки DDOS атак.
Реализуются как отдельные железки или агенты в составе веб серверов
• Инфраструктура самих ВС – приложения, развернутые на стандартной
платформе, плюс WSDL дескрипторы и реестры сервисов – механизм поиска
и исследования сервисов
• В доверенной зоне
• Провайдеры идентичности – сервисы установления идентичности,
поддержки SSO, объединения приложений для совместной работы с
идентичностью. Поддержка стандартов, прежде всего Liberty, обеспечивает
интероперабельность и доверенные отношения между отдельными
участниками и центральными провайдерами
• Директории – хранение данных пользователей, политик, ролей, ключей,
сертификатов и прочего. Основная форма – LDAP или аналоги
• Message Intercepter Gateway – шлюз перехватчик сообщений
• Проблема – необходимость построить единую точку применения политики
безопасности к входящим и исходящим XML сообщениям. Сообщения при этом
адресованы НАПРЯМУЮ точке веб сервиса
• Требуется
• Организовать перехват сообщений для анализа содержимого, блокировать
прямое обращение к веб сервисам
• Защищать доступ к WSDL описаниям и используемым схемам данных
• Осуществлять
• аутентификацию, авторизацию, шифрование / дешифрование, проверку
подписи
• противодействовать атакам на уровне содержания XML сообщений и их
вложений
• осуществлять контроль сообщений на правильность синтаксиса, соответствие
стандартам, схемам данных
• сжатие / деархивирование, трансформация, маршрутизация, контроль
целостности последовательности и корреляциии, контроль срока жизни
• направлять автоматические ответы для админа по выявленным атакам
• Дополнительные инфраструктурные сервисы – мониторинг, логирование, аудит,
отслеживание распределенных транзакций
• Решение
• Так как у нас ДМЗ, то при фильтрации входящих / исходящих запросов в
периметре можно организовать перехват всех сообщений с XML и отправку
через шлюз
• Для работы собственно с сообщениями используется отдельный компонент
MessageInstpector, в частности авторизацию запроса
• Может быть в форме отдельной железки или агента в составе того же веб
сервера, на котором развернуты веб сервисы
• Составляющие
 • MessageInterceptorGateway – перехватчик сообщений. Входящие отдает их для
анализа MessageInspector, по результатам передает ServiceEndpoint. Исходящие
также проверяет и отдает клиенту. Привязан к выбранному транспорту, также
может осуществлять защиту на транспортном уровне
• MessageInspector – анализатор сообщений XMLMessage, не зависим от
механизма транспорта сообщений. Точка осуществления аутентифиакции /
авторизации, применения политики безопасности
• ServiceEndpoint – веб сервис
• Стратегии
• XML Firewall – использование выделенной специализированной железки, с
точки зрения производительности и следования стандартам
• Веб агент в составе веб сервера – перехватывает запросы к сервису / ресурсам,
развернутым в составе данного сервера, более гибкое решение
• Последствия
• Централизация, вынесение функций защиты из приложений, возможность
защитить старые приложения, расширяемость
• Облегчение для клиента ситуации, когда разные сервисы используют разные
модели и механизмы безопасности, унификация, простота миграции на новые
технологии
• Улучшение тестируемости
• При использовании выделенных железок – увеличение производительности и
отзывчивости системы в целом. Для агентов все наоборот
• Факторы и риски
• Как любая центральная точка – необходимость высокой готовности,
отказоустойчивости и расширяемости
• Устойчивость к сбоям – после перезапуска должна подхватывать не только
новые запросы, но и те, которые были прерваны на пол пути
• MessageInspector – инспектор сообщений
• Проблема – реализация безопасности на уровне оконечных точек веб сервисов
приводит к излишнему связыванию между сервисами и механизмами безопасности.
Необходимо централизовать механизм проверок, обеспечить гибкость в части их
состава и параметров, обеспечить возможность контроля сообщений до/после
обработки, предоставить унифицированное API для процессинга сообщений в целях
обеспечения безопасности
• Требуется за счет анализа данных сообщения
• Идентифицировать и ограничивать поток сообщений на основе токенов,
подписей, корреляции сообщений, метод времени и централизованной политики
безопасности
• Проверять данные сообщения на уровне отдельных элементов, адресуемых как
XPATH / XQUERY
• Проверять сообщения на соответствия стандартам общим / технологическим /
корпоративным
• Осуществлять централизованное логирование, мониторинг, аудит,
администрирование
• Изолировать пользователя от необходимости использовать API различных
стандартов XML безопасности – WS-Security, XML digital signature / encryption,
SAML / REL token profile
• Решение
• Все выносится в отдельный модуль, который интегрируется в различные
инфраструктурные компоненты в зависимости от стратегии развертывания. Сам
модуль представляет собой цепочку обработчиков, по одному на конкретный тип
проверки, через которые прогоняются сообщения по пути туда и обратно.
 • Типовые задачи
• Проверка SOAP сообщения и его заголовков на совместимость со
стандартами WS-Security, XML digital signature / encryption, SAML / REL
token profile
• Идентифицировать и аутентифицировать автора сообщения за счет
обращения к провайдеру идентичности и
• Заголовков - WS-Security, XML digital signature
• содержимого сообщения – логин / пароль, SAML утверждение, REL
лицензия, бинарный токен в виде сертификата или Kerberos ticket
• Проверить сообщение или отдельные его части на целостность на основе
вычисления дайджеста и проверок подписей за счет WS-Security, XML digital
signature
• Проверить сообщение на конфиденциальность переносимых данных за счет
WS-Security, XML encryption
• Расшифровать / зашифровать сообщения перед / после дальнейшей обработки
за счет WS-Security, XML encryption
• Обратиться к XKMS провайдеру за открытыми ключами
• Проверить ИД корреляции, метку времени и срок действия сообщения
• Проверить данные на объем и формат представления, соответствие схеме в
виде DTD / Schema, отдельных SPATH / XQUERY
• Проверить данные на наличие атак за счет внедренных SQL, SPATH /
XQUERY выражений, межсайтовых скриптов, вредоносных URL, вирусов в
виде вложений и т.д.
• Автоматически ответить в случае обнаружения атаки, уведомить
администратора.
• Осуществление мониторинга, логирования и аудита
• Составляющие
• MessageInterceptor – входная точка осуществления политики безопасности,
• Принимает и обрабатывает SOAP RPC сообщения или просто XML
документы не зависимо от способа передачи. Изолирован от конкретного
транспорта за счет использования MessageInterceptorGateway
• настоятельно требуется, чтобы данные пользователя не кэшировались между
обработками отдельных сообщений
• за счет анализа структуры сообщения определяет применимость тех или
иных проверок, а также конечного адресата
• IndentityProvider – источник данных для идентификации / авторизации. Часто
производители снабжают их агентами для встраивания в веб сервера (reverse
proxy) или в стандартную цепочку интерцепторов веб сервиса
• MessageHandlerChain – управляет конфигурируемым набором проверок, каждая
из которых реализуется как MessageHandler
• Стратегии реализации
• Встраивается в отдельный сервер – XML Firewall или XML processing appliance.
Как правило, при этом либо просто совмещен с Gateway или обслуживает его в
части обработки перехваченных запросов
• Встроен в веб сервис как один или набор стандартных интерцепторов. Может
встраиваться как перехватчик, а дальше отправлять сообщения для проверки на
отдельный сервер. В зависимости от этого различается вычислительная нагрузка
на сервис
• Очень выгодно иметь промежуточное хранилище (базу данных) обрабатываемых
запросов в уже разобранном виде (например, в виде DOM), чтобы отдельные
обработчики не осуществляли парсинг документа с нуля. Снижается
вычислительная нагрузка, а также риск краха системы в целом и тяжелого
 подъема с нуля за счет краха одного обработчика при попытке распарсить
слишком большой кусок данных или timeout внешней операции
• Последствия
• Тяжелая вычислительная / алгоритмическая задача проверки вынесена из
конкретного приложения
• MessageInterceptor может использовать совместно всеми сервисами, может
повторно во многих системах
• Система расширяема за счет цепочки обработчиков
• Факторы и риски
• Результат обработки интерцептора может содержать конфиденциальные данные,
которые нуждаются в защите по пути к обработчику. Вообще по пути от
интерцептора к обработчику сообщение не защищено – возможность атаки
изнутри периметра
• Баланс между защитой и производительностью, особенно когда данных много
или частота запросов велика
• Во время обработки сообщений обработчики могут пересекаться на одних и тех
же данных, проблема конкурентного доступа
• Secure Message Router – безопасный маршрутизатор сообщений
• Проблема – осуществление совместного безопасного взаимодействия с множеством
сервисов на основе сообщений и единого пространства идентичности
• Шифрование / подпись ограничивают возможность следующего обработчика
изменить сообщение. Требуется тонкое разграничение по доступу на уровне
отдельных частей сообщения
• Фрагмент сообщения может быть «открыт» только для каких-то отдельных
обработчиков из процесса в целом. Разбивать же сообщение на отдельные
фрагменты и собирать потом может оказаться слишком сложным
• При использовании стандартного механизма защиты точка-точка сложно
поддерживать много точек обработки. Появляется потребность в SSO,
глобальной регистрации / удаления идентичностей, распределенного logout. Это
достигается использованием Liberty стандарта
• Требуется
• Централизованный инфраструктурный механизм для поддержки защищенного
workflow на основе XML сообщений
• Поддерживать политику безопасности на уровне фрагментов сообщений
• Поддерживать федеративную инфраструктуру безопасности на основе SSO,
SAML утверждений, XACLM прав
• Возможность динамически добавлять / удалять / останавливать сервисы.
Осуществлять глобальный logout
• Уведомлять участников процесса о изменении списка идентичностей
• Поддерживать множество схем данных, трансформировать сообщения при
передаче между отдельными обработчиками или применения механизмов
безопасности (канонизация перед подписью)
• Централизованный мониторинг, логгинг, аудит, обработка сообщений об
ошибках и т.д.
• Поддерживать контекст транзакций на основе веб сервисов
• Составляющие
• Client – приложение или Message Interceptor Gateway
• Secure Service Router – единая точка управления
• Message Configurator – поддержка безопасности на уровне сообщения в адрес
отдельного конечного сервиса. Выполнение необходимых проверок,
шифрования / дешифрования, контроля данных, внедрения токенов и т.д.
 • Identity Provider – сервис совместимый со стандартом Liberty, отслеживающий
набор используемых идентичностей и связанных с ним задач (SSO и т.д.)
• Участники: конечный – ServiceEndpoint, обрабатывает конечное сообщение, и
промежуточный – WorkflowRecipient, обрабатывает сообщение и пересылает
его дальше
• Стратегии
• XML Messaging Provider – роутер реализуется как входной веб сервис,
которому адресуется сообщение, предназначенное для обработки множеством
сервисов, передающим их друг другу. Схема обработки – цепочка
ответственности.
• Входное сообщение обрабатывается конфигуратором / провайдером
идентичности для адаптации к требованиям отдельных конечных
обработчиков
• Далее роутер осуществляет маршрутизацию до первого обработчика, тот
выполняет свою работу и передает следующему. Затем контролирует
результат и возвращает сообщения роутеру
• Далее сообщение приводится конечному виду и возвращается клиенту
• Liberty SSO - сообщение передается последовательно разным обработчикам,
схема обработки - звезда
• Все обработчики завязаны в единое сообщество доверия «circle of trust» на
основе Liberty провайдера
• В составе каждого обработчика есть Liberty агент, который умеет работать с
SAML токенами, а также общаться с посредством данного протокола с
провайдером
• Перед началом обработки сообщения у провайдера запрашивается SAML
утверждение - токен, которое помещается в сообщение. Далее оно
поочередно передается каждому участнику. Участник доверяет токену в
части безопасности обработки сообщения
• Последствия
• Централизованный контроль, модульность и изолированность логики
маршрутизации от логики прикладной обработки
• Повторное использование для защиты множества сервисов, удобство
тестирования
• Факторы и риски
• Как любая центральная точка – повышенные требования к надежности,
отказоустойчивости, расширению производительности
• Восстановление после сбоя – должно быть полностью прозрачное не только для
новых запросов, но и для уже обрабатывающихся в момент сбоя
• Удобство адаптации для новых стандартов
• Дополнительные советы
• Инфраструктура безопасности – закрыть доступ напрямую к сервисам в обход
инфраструктуры, проверять ИД хоста, запрашивающего операцию у сервиса,
использование VPN решения для общения с внешними сервисами, стандартные
решения создают меньше головной боли при интеграции, защита периметра и
фильтрация IP пакетов, специализированные XML устройства улучшают
производительность
• Взаимодействие и сообщения – ограничение публичного доступа к WSDL, схемам,
UDDI реестрам, автоматическая генерация WSDL из интерфейсов, использование
меток времени для ограничения срока жизни сообщений, использование ИД
корреляции, защита Fault фрагментов, которые могут содержать инфу, полезную для
взлома
• Развертывание и тестирование – регулярное тестирование на проникновение,
производительность, правильность логики, автоматическое уведомление в случае
 выявленных проблем, наличие резервных сервисов, поднимаемых в случае проблем
с основными, механизм «довыполнения» процессов упавшего экземпляра,

Identity management
• Особенности
• SAML утверждение
• Типы - данные об аутентификации, авторизации, атрибуты
• Данные – идентификаций предмета утверждения (IP, DNS адрес), source /
destination наименования
• Assertion Builder – построитель SAML утверждения
• Проблема – средство сбора воедино набора утверждений относительно
аутентификации Subject, его свойств, процесса авторизации. Используется как
клиентом, так и сервером.
• Требуется
• Иметь в одном месте всю логику построения набора утверждений трех типов
• Отделить логику построения утверждений от логики аутентификации /
авторизации
• Отделить код построения от среды использования для унификации работы с
клиентами различных типов - EJB, servlet, SOAP и протоколами – SOAP/HTTP
• Решение – логика построения выносится в билдер, который рулит сборкой и
созданием отдельных утверждений, процесс в целом провязывается отдельным
контекстом, изолирующим от протокола доступа и свойств среды
• Каждое утверждение создается в виде отдельного заголовка, имеющего тип,
условие и информацию. Логика создания утверждения изолирует построитель от
специфики конкретного продукта
• Общая логика: destination site создает при помощи построителя SAML пакет,
чтобы запросить данные аутентификации / авторизации от source site, который
выполняет функции SSO провайдера. Тот в свою очередь при помощи того же
построителя создает ответ. На основании данных ответа destination site решает
какой уровень доступа предоставить
• Построитель с контекстом определенного средой типа как правило получается из
JNDI контекста
• Составляющие
• AssertionContext – общий интерфейс контекста построения, для каждой среды
используется собственная реализации, использует различные утверждения для
чтения информации и кодирования с использованием соответствующего
протокола
• Утверждения – AuthorizationDecisionStatement, AuthenticationStatement,
AttributeStatement c коллекцией Attribute
• AssertionBuilder – создающий контекст
• Стратегии
• Использование контроля времени при обмене запросами и ответами
• Использование в составе SSO делегата или JCA коннектора для абстракции
доступа к инфраструктуре безопасности
• Последствия
• Защита от неправильного использования механизма аутентификации
• Замена и абстракции построителя утверждений от провайдера, возможность его
смены
• Отделения точки принятия решения об авторизации от точки его исполнения
• Отделение прикладной логики от сложности процесса, возможность как
синхронного, так и асинхронного запроса
• Факторы и риски
 • Лучше также защищать на транспортном уровне
• Можно запускать поверх надежного транспорта сообщений – SOAP/JMS
• Так или иначе работает поверх имеющейся инфраструктуры аутентификации /
авторизации, просто другой доступ
• SSO Delegator
• Проблема – необходимость скрыть от приложения все подробности взаимодействия
с инфраструктурой безопасности, поиска и вызова сервисов в распределенной
гетерогенной среде.
• Каждый вендор предлагает свой способ защищенного вызова сервиса, а также
использования инфраструктуры безопасности. Ускорении смены вендора, а
также подключения к системе нового приложения
• Хочется избавить прикладной код от учета данной специфики, а также от
дополнительных накладных расходов в случае, когда процедуры
идентификации / аутентификации выполняются при каждом вызове прикладного
сервиса –кэширование их результатов между отдельными вызовами
• Остальное стандартное – защита от изменений API сервисов, трансляция
исключений сетевых и безопасности, восстановление сбойных вызовов,
кэширование метаданных и разделяемых бизнес данных (справочников)
• Решение – вводится делегат между клиентом и сервисами, который связан с
инфраструктурой безопасности и с реестром сервисов.
• В отличии от просто бизнес делегата он выполняет работу по созданию и
передаче контекста безопасности, используемых токенов, взаимодействию с
инфраструктурой безопасности
• Каждый подключенный сервис идентифицируется уникальным ИД и
обслуживается отдельным модулем, который абстрагирует работу, необходимую
для организации безопасного вызова
• Составляющие
• SSODelegatorFactory – фабрика создания делегатов, подходящих для
конкретной инфраструктуры безопасности.
• Обеспечивает абстракции сервисов, связанных с безопасностью.
• Создает и предоставляет SSOConnection – соединение с инфраструктурой,
используемое для выполнения операций авторизации / аутентификации
• SSODelegator – входная точка, создается фабрикой в зависимости от окружения,
принимает запросы пользователя.
• Выполняет авторизацию пользователя за счет обращения к фабрике через
полученный при создании SSOConnection, результат, то есть сессию
безопасности, хранит в контексте.
• Для выполнения запроса вытаскивает из контекста свойства пользователя,
токен и оболочку сервиса, которой передает запрос
• Выполняет logout отдельного пользователя и глобальный logout, отключение
от SSO
• SSOContext – абстракция над средой работы и директорией публикацией
сервисов.
• Хранит ссылки на SSOServiceProvider по ИД-ам
• Хранит данные конкретных пользователей, в частности сессию безопасности,
между отдельными его вызовами
• SSOServiceProvider – оболочка вызываемого сервиса, устанавливает и
управляет соединениями с ним. Соединения могут быть разделяемыми между
всеми пользователями или персональными каждого пользователя
• Стратегии
• Использование Assertion Builder для абстракции взаимодействия с
инфраструктурой безопасности
 • Реализация глобального logout пользователя как последовательного logout
пользователя из всех сервисов, а затем из инфраструктуры в целом
• Последствия, кроме стандартных для делегата
• Ликвидируется возможность обращения клиента к сервису без начальной
аутентификации. Нет возможности для попытки подменить сессию
• Минимальное число обращений к SSO
• Повышается надежность за счет использования нескольких входов как для
инфраструктуры безопасности, так и для сервисов
• Факторы и риски
• Кэширование идентифицирующей клиента информации требует тщательной
защиты механизма в части разделения памяти
• Слишком много промежуточных абстракций
• Не поддерживается использование нескольких центров аутентификации /
доверенных сообществ
• Связанные шаблоны – Assertion Builder, Credential Tokenizer, Service Locator
• Credential Tokenizer – работа с токенами безопасности
• Проблема – мандат пользователя (user credentials, security token) может быть в
разных формах (логин / пароль, X.509 сертификат, Kerberos ticket, SAML token).
Необходимо унифицировать процесс работы с токеном, абстрагировав его от
подробностей выбора инфраструктуры, протокола, среды клиента и т.д.
• Требуется
• Выделить логику создания и использования токена в отдельный повторно
используемый компонент
• Изолировать высокоуровневые процедуры от подробностей выбора провайдера
безопасности и общей инфраструктуры
• Решение – компонент, абстрагирующий взаимодействие с провайдерами
безопасности посредством собственного API и модели представления токена
безопасности
• Инфраструктуры – Java безопасность, SOAP сообщения, SAML утверждения,
унаследованные приложения, SSO
• Абстракции – сервис аутентификации, схема процесса – создание запроса на
аутентификацию и получение результата аутентификации, используемый
протокол доступа , инфраструктура среды развертывания.
• Составляющие
• SecurityToken – абстракция токена, наследники реализуют конкретные типы
токенов
• TokenContext - системные контекст, в котором хранятся тип токена, данные
принципала, конфигурация доступа к сервису, настройка используемого
протокола. Предоставляет публичное API конфигурирования процесса, главный
метод – создать и получить токен
• CredentialTokenizer – получает необходимую информацию из контекста,
связывается с провайдером, на основании полученной от него информации
создает токен
• Стратегии
• Использование абстракции провайдера аутентификации в виде общего
интерфейса
• Использование абстракции для поиска сервиса и протокола доступа
• Кэширование однажды полученного токена пользователя для снижения нагрузки
на сеть / сервисы
• Последствия
• Может использоваться в процессе SSO для организации совместного доступа
приложений к токенам пользователя
 • Требуется анализ уязвимости при выборе используемого типа мандата.
Взаимодействие с провайдером должно защищаться, например на основе
SecurityPipe
• Дополнительные советы
• Функции управления идентичностью и определения политики должны быть
выделены в отдельную часть системы как программно, так и административно
• Любые изменения в данных / правах пользователя должны логироваться, причем
безопасно
• Большинство шаблонов представляют собой единую точку доступа – повышенные
требования к надежности, расширяемости, восстановлению после сбоя с
продолжением прерванных процессов
• Для поддержки SSO стандарт использования SAML / Liberty
• Максимально слабая точка – использование повторно используемых паролей,
чувствительно как к перехвату, так и к подбору. Другая частая опасность –
использование дефолтных настроек инфраструктуры

Secure Service Provisioning – подготовка сервисов к использованию

пользователями
• Общие замечания
• Service Provisioning – централизованное управление процессом распределения
данных пользователя среди корпоративных приложений, операционных систем,
серверов и т.д. Используется вместо ручного управления профилями одного
реального пользователя в каждой из систем отдельно.
• Основные процессы – создание, маппинг между собой пользователей в разных
системах, установка свойств профиля, присвоение прав, смена прав в связи с
изменением свойств пользователя (например, перехода в другой отдел), смена
пароля (в соответствии с различными ограничениями на пароль в каждом из
приложений), синхронизация пароля между системами, разрешение / запрещение
доступа, удаление, уведомление других информационных систем.
• Поддерживается специализированным протоколом – SPML, абстрагирующим
операции работы с различными провайдерами безопасности, к которым подключены
прикладные системы
• Основные операции - добавить, удалить, модифицировать, найти (стартовая
точка, фильтр, перечень запрашиваемых атрибутов), специфические для
приложения (ид провайдера, ид операции, атрибуты). В ответ данные или
сообщение об ошибке – код, локальный для системы, и текстовое сообщение для
администратора
• Поддерживаются синхронные операции – высылаем один и ждем пока сервер
ответит, потом следующий запрос. Такой режим в основном для унаследованных
систем. Асинхронный – высылаем одновременного много запросов, которые
обрабатываются приложением асинхронно.
• Предъявляет повышенные требования к безопасности, надежности и скорости.
Особенно потому, что относительно каждой управляемой системы имеет слишком
большой набор прав
• Процесс может включать много этапов, подразумевающих взаимодействие многих
пользователей, утверждение, определение свойств, поэтому широко используются
workflow системы
• Может отдельно различаться «user account provision» и «service provision», второе
подразумевает настройку ПО под пользователя, учетная запись которого в системах
уже есть.
• Не включает в себя, а использует аспекты федеративной аутентификации /
авторизации пользователей. Источников идентичности может быть несколько, SP
предоставляет унифицированный стандартный интерфейс работы с ними, вне
 зависимости от их вендора и расположения – аналог бизнес делегата. SSO также не
входит в область ответственности – предоставляется провайдерами идентичности
• Архитектуры
• Централизованная – выделенный сервер под ПО и хранилище профилей
пользователей, затем они выгружаются в хранилища отдельных приложений,
• Способы интеграции с приложениями
• поддерживают SPML протокол управления пользователями
• специализированные для конкретного SP внедренные агенты управления. SP
как правило предоставляет SDK для из разработки
• отдельно запущенные агенты, которые ходят внутрь по стандартным
протоколам, например JDBC. Могут быть запущены в том числе и на сервере
SP
• Плюсы – единая точка управления, унифицированный пользовательский
интерфейс, автоматизация процесса
• Минусы – повышенные требования к надежности центральной точки
• Типовые компоненты – интерфейс пользователя, мониторинг, менеджер паролей,
анализатор рисков, фабрика соединений с прикладными системами, анализатор
рисков
• Базовые сервисы – машина правил, workflow, сервис синхронизации,
выравнивание профилей между системами, доступ к SPML совместимым
приложениям
• Распределенная – одно из приложений выбирается как первичное хранилище
пользователей, затем данные из него реплицируются в остальные приложения.
Обычно это какая-то ERP система, в которую уже вложено много средств и в
которой ведется основное управление пользователями. Процессом управляет Help
Desc, который имеет доступ к интерфейсам всех систем
• Плюсы – надежность
• Минусы – трудность синхронизации, использование различных
пользовательских интерфейсов для работы с конкретными ПО, несовместимость
процессов, проблема с маппингом данных и интеграцией
• Сервисные компоненты
• Сервис директорий – используется прикладными системами для управления
профилями пользователей, SP соответственно может стучаться не к
приложениям, а сюда. Для доступа может использоваться стандартный протокол
DSML
• Сервис идентификации – приложения могут там хранить данные о пользователях
и использовать для реализации SSO, соответственно тоже активно используется
SP. Также SP хранит там идентичности собственных админов
• Портальная интеграция – предоставление на основе портлета / портлетов доступ
к консоли сервера, а также к интерфейсам управления отдельных систем. В
частности реализует SSO совместного доступа
• Password Synchronizer – синхронизатор паролей
• Проблема – необходимо организовать синхронизацию пароля или других данных,
используемых для аутентификации / авторизации, между множеством программных
платформ
• Требуется
• Взаимодействовать с различными механизмами администрирования каждого из
приложений
• Поддерживать различные протоколы взаимодействия в гетерогенной среде,
инфраструктуры поиска и вызова сервисов.
• Поддерживать асинхронное выполнение запросов, а также взаимодействие с
периодически не работающими приложениями
 • Стандартизировать обработку результатов операции по каждому из приложений
• Решение – реализовать специальный сервис, в котором скрыть всю логику процесса
распространения паролей, а организацию также взаимодействия. Фактически – хаб
или фасад запросов
• Клиенты – веб сервис, J2EE приложение, устройство доступа
• Базовые составляющие
• Менеджер
• книга учета операций (ledger) – исходный запрос порождает ряд вторичных
запросов к отдельным приложениям, которые выполняются независимо. По
мере их выполнения меняется статус исходного запроса.
• В основном применяется для асинхронного взаимодействия с
приложениями, которые не являются всегда онлайн или обладают
непредсказуемым временем отклика. Хорошо использовать асинхронный
обмен сообщениями
• Поддержка возобновления уже начатых процессов после перезагрузки
или краха сервера
• Может использоваться для отката операции в целом, если на каком-то из
приложений ее выполнить не удается.
• таблица маппинга пользователей сервиса - ID, на пользователей отдельных
приложений – PSTID (provision service target ID). PSTID могут отличаться
между собой и от ID
• Структура
• PasswordSyncRequest – исходный запрос, направляется PasswordSyncManager
• PasswordSyncManager – центральная точка доступа
• Вытаскивает из хранилища центральный профиль пользователя в виде
ProvisioningUserProfile
• Загружает конфигурацию набора приложений а также маппиг пользователей
при помощи ServiceConfig, инициализирует контекст процесса
• Для каждого приложения инициализирует адаптер доступа в виде
ProvisioningServicePoint. Адаптеры могут быть нативными, общего
протокола ( JDBC), специализированного протокола (SPML). На них
поддержка сессии работы с приложением и защита менеджера от всей
специфики обмена
• Создает ряд запросов к каждому из приложений и кладет их в книгу –
PasswordSyncLedger
• Выбирает неисполненные запросы из PasswordSyncLedger и отправляет
приложениям при помощи ProvisioningServicePoint. При синхронном ответе
отмечает запросы как использованные сам
• PasswordSyncListener – получает уведомления от приложений об исполненных
асинхронных запросах и отмечает их в PasswordSyncLedger
• PasswordSyncLedger – хранит отдельные запросы до их выполнения, а потом на
случай отката. Предоставляет статистику по процессу
• Стратегии
• Многопоточность – для ряда приложений ВСЕ запросы должны выстраиваться
в очередь, некоторые допускают параллельное выполнение. Выборка запросов из
книги и их выполнение – принципиально многопоточная задача. Также
многопоточность порождается подпиской на асинхронные ответы приложений,
например через JMS
• Пост-обработка синхронизации – уведомление админа / пользователей об
выполненной операции смены пароля. Более сложные workflow обычно на
менеджер не возлагаются
 • Откат – на основании лимита времени или попыток смены пароля для
конкретного приложения. Уже выполненные запросы в книге откатываются
обратно. Проблема – зачастую из приложения старый пароль не вынешь и не
сохранишь, например из ЮНИКС систем. Хранение всех паролей у себя –
дополнительный риск. То есть либо откат возлагаем на само приложение, либо
он храним все пароли.
• Последствия
• Слабое место – взлом центральной точки передает под контроль атакующего все
приложения разом за счет возможности сменить пароли
• Строгая необходимость использования защищенного хранилища, каналов до
приложений на разных ключах. Хорошая практика использование SSO
абстрагированного за счет делегата
• защита используемых сервисов приложений от доступа со стороны других
хостов кроме менеджера
• Прием запросов только от приложения администратора, запрет на прием от
управляемых приложений
• Обязательное защищенное логирование операций
• При обмене сообщениями – защита от перехвата и повторного проигрывания:
метка времени, корреляция, XML шифрование и подпись
• Факторы и риски
• При большом количестве приложений и/или пользователей – точка повышенной
нагрузки, допускается баланс между несколькими установками и одной базой.
Минимум три сервера.
• Желателен контроль качества операций, из-за непредсказуемости времени ответа
приложения затруднен

Локализация
общее
• связь между регионом и языком зачастую не одна к одному.
• Локализация затрагивает
• Текст, графика, звук
• Форматы чисел, дат, времен, валют
• Разница в законах: ограничения на правила публикации данных, правила
совершения сделок, особенно через платежные системы
• Интернационализация - I18n, вынесение зависимости от локали из кода приложения,
архитектурно – дизайнерская задача
• Локализация - l10n, формирование для приложения конкретной локали, чисто
девелоперская задача невозможная, без предварительно обеспеченной
интернационализации

Протоколы
Унаследованные системы и интеграция
общее
• Использование интеграции EEJ - EIS
• Расширить пользовательский интерфейс системы
• выставить унаследованную систему в качестве веб приложения
• встроить УС в межплатформенную интеграцию
 • встроить УС в В2В взаимодействие, где EEJ приложение выступает как медиатор
между многими унаследованными решениями
• усилить безопасность УС и надежность обработки данных
• Типы интеграции по направлению передачи данных
• Inbound - ВС обращается с запросом к системе
• Outbound – система запрашивает ВС
• Механизмы интеграции
• Через обмен файлами
• Много инструментов малой автоматизации обработки файлов
• Просто реализуется, разработчики должны знать только форматы файлов
• Малофункциональны, многие функции систем таким образом не доступны
• Может быть значительная нагрузка по перекодировке файлов, зачастую с
привлечением сторонних данных
• Низкая частота обмена данными, системы все время находят в состоянии
частичной рассинхронизации
• Через пользовательский интерфейс или «screen scraping»
• Грубая интеграция, все передаваемые типы данных должны базироваться на
фрагментах интерфейса
• Можно использовать, когда развитая типизация передаваемых данных не
существенна, например при получении / отправке текста или простого набора
полей
• Зачастую требует выполнения минимального объема работ для выполнения
интеграции
• Плохо масштабируемый механизм, так как EIS зачастую просто не рассчитана на
соответствующее количество пользовательских запросов
• Через вызовы, локальные или RPC, данные передаются как параметры
вызовов
• приложения поставляют функциональность бизнес уровня и не предоставляют
доступ к системным данным и механизмам. Лучшая инкапсуляция
• Синхронные, тесно связанные вызовы через специальный адаптер или JCA /
специализированный интерфейс
• Требует «Data Mapping» - выполнения двунаправленного преобразования типов
данных
• Обычно поддерживается визуальным инструментарием, предоставляемым
EIS
• Может реализовываться за счет маппинга CMP EJB бинов на JCA, хотя это и
не стандартная опция
• Затруднена, если имеющееся API не предусматривает участие системы в
распределенной транзакции
• Достоинство – подробное API, развитые типы данных, облегченная передача
кодов ошибок и исключений между системами
• Недостаток – сильно связанное решение
• Интеграция по данным – общая база данных
• с использованием JDBС для реляционных данных и JCA/CCI для не
реляционных
• Данные представлены в data / record виде
• Также необходимо производить маппинг данных и преобразование форматов
• Многое ПО работает с базой в закрытом режиме и не раскрывает подробностей
устройства и функций работы.
• Особенно неприятно, если значительная часть логики работы с данными
расположена не в базе и ее приходится дублировать в составе других систем
 • При смене версии производитель может внести изменения в схему базы не
предупредив пользователей
• Повышается вероятность блокировки данных при совместном использовании
• Асинхронный обмен сообщениями
• Минимально связывает приложения между собой, только через формат
передаваемых сообщений
• Основные подходы – JMS, SOAP
• Хорошо подходит для приложений, взаимодействующих через Интернет
• Менее чувствительна к сбоям в инфраструктуре и отдельных системах
• Возможен как синхронный, так и асинхронный обмен данными
• Также может порождать частичное рассогласование данных в системах
• Событийно управляемый механизм – труднее разрабатывать и тестировать
• Использование интеграции через вызовы API
• усложняется необходимостью понимания – домена приложения, его транзакционной
модели, его модели безопасности
• основные технологии реализации – JNI, Corba, RMI
• типы взаимодействия:
• простой адаптер – маппинг API EIS в многократно используемое API на стороне
Java
• Реализации – Java приложение, JNI, библиотека - нативный адаптер EIS,
нативный протокол, EIS
• Как правило, при таком подходе не возможно использовать поддержку со
стороны JEE для транзакционности, безопасности и масштабируемости
• Распределенный адаптер – отдельно развертываемый компонент,
обеспечивающий доступ к EIS для многих компонентных моделей, платформ
взаимодействия и архитектур
• Реализация - Java приложение, стаб, RMI, скелетон на сервере адаптера,
нативный адаптер EIS в составе сервера, нативный протокол, EIS
• Используемый термин – «Off-board server»
• Использование JCA
• Нет необходимости использовать JNI/RMI для поддержки взаимодействия с
EIS
• Вендору EIS нет необходимости отдельно интегрироваться с каждый
сервером приложений
• облегчается переносимость EEJ приложений между серверами
• Обязанность предоставление коннектора лежит на производителе
нового типа EIS и не требует какой-либо активности со стороны
производителей серверов приложений
• Основная сложность с эксплуатирующейся старой системой (legacy) в том, чтобы
совместно использовать ее данные не нарушая их целостность
• Best practices
• Использование одной точки входа логической и физической, чтобы координировать
доступ, контролировать его и не допускать проблемы с целостностью данных
• Входную точку хорошо оформлять как DAO и уже его использовать со стороны EJB
бинов.
• Под DAO может быть как JCA, так и простой адаптер в зависимости от того, что
удобнее
• Пример использования шаблона Bridge, когда интерфейс и реализация
эволюционируют независимо
• Приложения защищается от изменения механизма доступа к EIS, смены его
версий и т.д.
 • DAO должно отражать в большей степени потребности клиента EIS, чем
внутреннюю организацию EIS
• Если выполнение операции требует нескольких вызовов к EIS, то эти вызовы
надо реализовывать внутри, скрыто для клиента – шаблон фасад
• Обеспечение проверки данных и их целостности
• Если база современная и поддерживает триггеры / процедуры – то лучше в ней,
нет необходимости дублировать логику и в бинах, и в базе.
• Плюсы
• Сервис совместно используется всеми подключенными к базе
приложениями. Нет возможности испортить что-то обратившись в обход
бинов, реализующих логику проверки
• Централизованный контроль над операциями
• Переносимость между различными вендорами БД
• Надежность и производительность – в это инвестировано много денег
вендоров и есть некоторая надежда
• Когда операции требуют оперирования большими объемами данных –
нет необходимости тащить их по сети
• Минусы
• Скорее всего, придется все же дублировать логику проверки.
• Тогда исключения из базы будут использоваться не штатно, а
свидетельствовать об ошибках в логике бинов.
• Синхронизация двух логик, а также их параметров будет
представлять проблему
• Если код проверок сложный, то проблема несовместимости между
различными СУБД
• Развертывание распадается на две части, возможно несовпадение двух
развертываемых частей системы и их настроек, проблемы с
обслуживанием
• Можно вынести все в бины. Плюс – совместимость с различными СУБД,
достигаемая контейнером, легкость развертывания и настройки
• И там и там, все параметры контролей задаются отдельно и применяются в
процессе развертывания. Нужно, когда работаем на многих базах и
одновременно нужна большая производительность
• Выделение специального сервера под доступ к данным, на него возлагаются
обязанности всех контролей – декоратор. Сложно проектировать и
разрабатывать, зато очень гибко и переносимо
• Использование специального transaction processing monitor (TP), который
может опираться на различные БД
• Терминология
• Монитор транзакций - среда развертывания компонент, участвующих в
распределенных транзакциях
• Off-board server – выделенный сервер-прокси для доступа к унаследованной системе
• CORBA от RMI
• RMI – клиент, стаб, скелетон, сервер
• CORBA – клиент, стаб, ORB, скелетон, сервер

Обзор JCA
• Архитектура основана на EIS адаптере ресурса, включенном в состав J2EE сервера и
взаимодействующем с EIS по нативному протоколу
• Может загружаться и использоваться как в управляемом окружении - 3х звенка, сервер
приложений, так и в неуправляемом – 2х звенка
• Основные пакеты
• Javax.resource.cci – поддержка Common Client Interface (CCI).
• Javax.resource.spi – поддержка системного контракта
• Адаптер реализует прозрачно для компонентов J2EE приложения поддержку
системных механизмов:
• Изначально, с версии 1.0
• Транзакции
• возможность объединять множественные вызовы компонента в одну
транзакцию и откатывать целиком. В том числе, когда несколько
взаимодействующих компонентов используют EIS в одной операции. Без JTA
транзакции (только локальными для каждой компоненты) организовать такой
откат будет крайне сложно
• альтернативный способ – компенсационные транзакции, используются когда
JTA недоступны. Не всегда возможны, нарушается атомарность. При
многопоточном доступе EIS может оказаться в несогласованном состоянии
• Опциональная возможность в контракте, разработчики адаптера определяют
какой уровень поддержки транзакций реализуется:
• Без поддержки
• Только локальные транзакции, включающие только одну EIS систему и
менеджер ее ресурсов. Существует ТОЛЬКО внутри EIS, то есть
автоматического распространения транзакции изнутри сервера
приложений в EIS не происходит
• Распределенные транзакции с одно или двухфазным подтверждением,
распространяемые из сервера приложений внутрь EIS
• Безопасность
• Коннектор реализует аутентификацию пользователей в EIS и другие
специфические для EIS операции
• Для сервера приложений доступно два подхода к реализации безопасности
• Управляемое контейнером SSO, полномочия конфигурируются, когда
адаптер регистрируется в системе.
• Включается в XML дескрипторе бина через resource-ref/res-
auth=Container
• Варианты конфигурирования
• Configured identity - Все соединения адаптера с EIS используют одну
и ту же идентичность
• Principal mapping – идентичность пользователя сервера приложений
мапится на идентичность соединения
• Caller impersonal – идентичность в сервере приложения и в EIS
совпадают
• Credential mapping – то же самое, что и в предыдущем случае, но для
некоторых идентичностей используется маппинг
• Управляемое компонентами SSO, идентичность предлагается
компонентом при каждом получении соединения
• Включается в XML дескрипторе бина через resource-ref/res-
auth=Application, аутентификация производится через методы
ConnectionFactory при получении cci.Connection
• Управление соединениями
• пул соединений - реальные соединения управляемо создаются, выделяются
для использования прикладному коду и сбрасываются
• возможность минимизировать число физических соединений с EIS
относительно числа пользователей java приложения
 • более эффективное использование ресурсов EIS – меньше памяти,
выравнивание нагрузки во времени
• Начиная с версии 1.5 – расширенный контракт, основная особенно – поддержка
асинхронного взаимодействия
• Жизненный цикл адаптера - действия выполняемые при запуске и остановке
адаптера ресурсов
• Управление заданиями, которые адаптер выдает серверу для выполнения,
использование пула нитей сервера вместо реализации собственного
• Распространение (inflow) транзакций, начатых в EIS, на сторону сервера
приложений
• Управление потоком сообщений со стороны EIS в очереди и топики сервера
приложений
• Поддерживаются JMS и JAXM сообщения
• Позволяет EIS инициировать процессы в сервере приложений.
• Позволяет в отличии от стандарта JCA 1.0 реализовывать асинхронное
взаимодействие
• Два уровня контракта
• Системный уровень – сервера с самим адаптером, интеграция
инфраструктурных системных сервисов прозрачно для прикладных компонент
• Прикладной уровень – предоставление прикладным компонентам API доступа,
• Специфического для EIS
• Общего Common Client Interface (CCI)
• Поставка и развертывание коннектора
• Классы в корне, ra.xml в WEB-INF, в нем
• Корень - connector
• Наименование коннектора, имя вендора, тип EIS, версия адаптера
• В connector/resourceadapter-class – наименование класса адаптера

Реализация JCA адаптера – 1.0

• Управление соединениями - реализуются в составе пакета SPI
• ManagedConnectionFactory – фабрика производитель
• как системных, управляемых соединений - ManagedConnection, так и CCI
соединений (интерфейс для них стандартом не специфицируется - Object)
• Выполняет функции пула физических соединений
• Создает фабрики соединений для CCI интерфейса – ConnectionFactory
• Тип создаваемой фабрики соединений не определен
• Может создаваться на основе передаваемого сервером приложений объекта
ConnectionManager,
• используется сервером приложения для запроса управляемых соединений
• как именно не специфицируется, в неуправляемой среде не применяется
• Создает управляемые соединения ManagedConnection, которые 1-* соотносятся
с CCI соединенями
• ManagedConnection – системное соединение с EIS, 1:1 соответствует
низкоуровневому соединению
• Предоставляет серверу реализации интерфейсов XAResource для включения в
распределенную транзакцию и LocalTransaction для осуществления локальной
транзакции
• Создает из-под себя CCI соединения и присоединяет их. Предоставляет
метаданные EIS в виде ManagedConnectionMetaData
• Сервер приложения может регистрировать слушатели событий системного
соединения как экземпляры ConnectionEventListener
 • События закрытия соединения, возникновения ошибки
• События для локальной транзакции начала, завершения и отката
• Запрос как системного, так и CCI соединения может уточняться через
ConnectionRequestInfo. Что это такое не уточняется, как правило, хранилище как
минимум для логина и пароля.

Реализация JCA адаптера – 1.5

• Управление жизненным циклом
• Через методы интерфейса ResourceAdapter в пакете SPI
• void start(BootstrapContext ctx), за счет BootstrapContext адаптер в
процессе инициализации и впоследствии может
• создать таймер - Timer createTimer()
• получить менеджер управления заданиями - WorkManager
getWorkManager()
• получить объект для завершения и отката транзакций, начатых в EIS -
XATerminator getXATerminator().
• void stop()
• Управление заданиями, выполняемыми в интересах адаптера сервером
приложений
• Инфраструктура в пакете javax.resource.spi.work
• Со стороны сервера приложений заданиями управляет WorkManager
• Адаптер получает его во время инициализации и затем использует для
управления выполнением заданиями, синхронным и асинхронным
• doWork – выполнение задания синхронно, если сервер загружен это может
занять много времени, если сервер должен перезагрузиться он вызывает на
такой задаче release
• startWork – добавить задачу и дождаться начала ее выполнения
• scheduleWork – добавить и сразу вернуться, нет гарантии, что задание будет
выполнено
• адаптер может уведомляться о ходе выполнения задания через WorkListener,
передаваемый этим методам как параметр. Уведомление приходит о добавлении
задания, запуске, завершении и удалении из очереди
• При запуске может передаваться контекст выполнения ExecutionContext
определяющий
• Таймаут для транзакции, в которой будет выполняться задание
• Идентификатор транзакции, если задание уже принадлежит к ней - Xid
• Задание представлено как work, реализующее Runnable
• void release() – способ для WorkManager уведомить активное задание, что
его выполнение надо прекратить как можно быстрее. Например, в случае
опускания сервера приложений
• Управление сообщениями и транзакциями, исходящими из EIS и передаваемыми
на сторону сервера приложений
• Void ResourceAdapter.endpointActivation(MessageEndpointFactory endpointFactory,
ActivationSpec spec) – возможность для адаптера зарегистрировать точки доставки
сообщений
• MessageEndpointFactory – интерфейс для создания точек доставки
• MessageEndpoint createEndpoint(XAResource xaResource) – регистрация
точки доставки
• boolean isDeliveryTransacted(Method method) – выяснение является ли
доставка определенному методу слушателя сообщений транзакционной или
нет
• ActivationSpec – маркер, бин является перевозчиком свойств
 • Метод validate, проверка консистетности набора значений свойств
• Get метод доступа к адаптеру ресурсов
• Нельзя переопределять equals
• void endpointDeactivation(MessageEndpointFactory endpointFactory, ActivationSpec
spec) – возможность для адаптера деактивировать точки доставки сообщений
• XAResource[] getXAResources(ActivationSpec[] specs) – вызывается сервером
приложений, восстанавливающимся после краха
• XAResource – контракт между Resource Manager и Transaction Manager,
позволяет в данном случае для конкретного ресурса откатить начатую
транзакцию

Поддержка CCI
• Опциональный, не требуется обязательная поддержка поставщиком адаптера,
вместо этого тот может предоставить собственное специальное API
• Разделы интерфейса, реализуется в составе пакета CC
• Установка соединений
• ConnectionFactory – фабрика создания соединений, предоставляется
ресурсным адаптером.
• Приложения получает фабрику через JNDI и создает с помощью нее
соединение Connection за счет методы getConnection()
• Методу может быть опционально переданы дополнительные данные за
счет объекта типа ConnectionSpec, в который например могут быть засунуты
логин и пароль доступа
• Connection – соединение уровня приложений
• способ доступа к ниже лежащему системному соединению,
представленному как ManagedConnection
• может создать один или несколько объектов Interaction -
компонентов для выполнения EIS функций
• можно получить описание соединения как ConnectionMetaData
• Выполнение заданий
• Задание представлено объектом Interaction, создаваемым как Connection.
createInteraction()
• Получают / очищают предупреждения, представленные как
ResourceWarning, фактически это невозбужденные исключения –
сообщение, код, ссылка на нижележащее исключения
• Выполняют действия, представленные как InteractionSpec
• Record execute(InteractionSpec ispec, Record input)
• Boolean execute(InteractionSpec ispec, Record input, Record output)
• Действие InteractionSpec представляет собой набор свойств, определяющих
чего же надо делать, например – схему данных, каталог, имя вызываемой
функции и т.д.
• Выполнение запросов и получение данных
• Именованный набор данных с описанием – Record
• Может использоваться как входные и выходные данные вызова,
определенного через InteractionSpec
• Две версии - IndexedRecord и MappedRecord для различного доступа к
полям
• реализуют соответственно List / Collection и Map
• создаются двумя методами фабрики RecordFactory, получаемой от
ConnectionFactory
• Работа с метаданными
 • Описание соединения с EIS – ConnectionMetaData, можно получить
наименование и версию продукта, наименование пользователя от имени
которого установлено физическое соединение
• Описание адаптера – ResourceAdapterMetaData
• наименование, краткое описание и версия адаптера
• наименование производителя, кроме того
• перечень ИД поддерживаемых спецификаций
• ? поддержка двунаправленного обмена записями
• ? поддержка вызова метода с входным набором записей
• ? поддержка локальных транзакций

RMI
Основы
• Общая идея
• Сервер создает один / несколько удаленных объектов, публикует ссылку на них в
реестре и ждет вызовов
• удаленный объект удерживается от сборки как локальными, так и удаленными
ссылками
• До 2 версии нужно было генерировать при помощи rmic и скелетон и стаб.
Начиная со второй версии – только стаб, вместо скелетона используется
отражение. Начиная с версии 1.5 – вообще ничего генерировать не надо, клиент
использует динамический прокси
• Клиент получает ссылку на удаленный объект из реестра и вызывает на нем какие-
то методы.
• Альтернативным путем получения ссылки на удаленный объект является вызов
метода локального / удаленного объекта, возвративший такую ссылку.
• Клиент не может непосредственно создать объект на сервере, может
активировать заранее подготовленный за счет технологии Remote Object
Activation
• RMI инфраструктура предоставляет механизм обмена данными между клиентом и
сервером.
• Протоколы
• JRMP – есть разные реализации, например Voyager
• RMI-IIOP, совместима с CORBA, не поддерживает ряд возможностей RMI
• загрузка классов, которые еще не были известны серверу / клиенту до этого.
Например, с общедоступного веб сервера. Классы НЕ передаются по сети,
вместо этого в стабе передаются URL ресурса, с которого может быть считан
класс
• Серверная часть
• Определяется удаленный интерфейс объекта через расширение java.rmi.Remote.
• Все методы такого интерфейса должны кроме прикладных исключений
возбуждать java.rmi.RemoteException, сигнализирующее проблемы на сетевом
уровне – доступность или протокол
• Параметры методов – примитивы, удаленные объекты, сериализуемые объекты
• При передаче удаленного объекта вызывающему коду в другой JVM происходит не
копирование, как в случае локальных объектов, а создание stub-а, сохраняющего
связь с объектом и выполняющего роль удаленного прокси.
• То есть удаленный объект передается как копия ссылки, зарегистрированной в
реестре или являющейся свойством другого объекта
 • Стаб реализует удаленный интерфейс объекта. В стаб записывается адрес
сервера, на котором объект находится. Он определяется автоматом, но иногда
криво и тогда можно его задать как свойств JVM - Java.rmi.server.hostname
• Клиентом могут быть вызваны только методы данного интерфейса вне
зависимости от того, какие еще методы / свойства есть у первоначального
объекта
• Стаб может реализовывать экзотические модели вызова – например, на
несколько экземпляров удаленных объектов на разных серверах одновременно.
Пользоваться результатом, полученным первым
• Сам удаленный объект никогда не покидает JVM, где он был создан. Можно
передать принудительно:
• Сериализовав в массив байт или в поток ввода-вывода
• Использовать делегат, реализующий Remote, и обычный сервисный объект,
который можно обычным образом передать в другую машину
• Используемый в качестве аргумента сериализуемый объект может определить
private static final serialVersionUID, чтобы различать версии данных,
соответствующие классов. Иначе – любое изменение класса приведет к
несовместимости
• Шаги процесса
• Установить менеджер безопасности, чтобы дать возможность RMI загружать
классы откуда-нибудь еще, кроме как из локального пути
System.setSequrityManager(new SecurityManager())
• Создать для удаленного объекта стаб. Можно указать порт, 0 – предоставить
возможность самому RMI это сделать
RemObject remObject = new RemObjectIml();
RemObject stub = (RemObject) UnicastRemoteObject.exportObject(remObject,0)
• Получить доступ к реестру и опубликовать в нем стаб удаленного объекта.
• Все вызовы к реестру осуществляются удаленно, поэтому-то и нужен стаб
• По умолчанию реестр поднимается на 1099, но можно указать и другой адрес
• Операции bind, unbind, rebind можно производить только на своем хосте,
lookup – на любом
• По окончанию публикации нет необходимости заставлять нить ждать
опубликованный объект. Реестр держит объект пока он не депубликован И
пока на него есть ссылки
• Пример
Registry reg = LocateRegistry.getRegistry();
Reg.rebind(name,stub)
• Можно не реализовать Remote, а расширить UnicastRemoteObject, реализовав
конструктор выбрасывающий RemoteException и вызывать super. В этом случае
объект сразу становится удаленным и экспортируется автоматически. Биндить все
равно надо явно.
• Вместо Registry можно использовать Naming c теми же методами. Вместо отдельно
хоста / порта методы используют URL формата «rmi://host:port/service»
• Клиентская часть
• Удаленная ссылка кроме интерфейса удаленного объекта также реализует
служебный интерфейс RemoteRef, позволяющий обращаться в общем стиле к
удаленному объекту:
• Object invoke(Remote obj, Method method, Object[] params, long opnum) –
вызов метода
• boolean remoteEquals(RemoteRef obj) – проверка эквивалентности серверных
объектов
• int remoteHashCode() – хэш код удаленного объекта
• String remoteToString() – строковое представление удаленного объекта
 • Шаги процесса
• Опять-таки менеджер безопасности, чтобы обеспечить загрузку не известных
классов
• Получить доступ к регистру на сервере
Registry reg = LocateRegistry.getRegistry(host, nPort);
• Получить объект
RemObject stub = (RemObject) reg.lookup(name)
• Использовать объект
• Вместо Registry можно использовать Naming c теми же методами. Вместо отдельно
хоста / порта методы используют URL формата «rmi://host:port/service»
• Клиент может дать возможность серверу в ответ вызывать себя, создав удаленный
объект и передав его стаб серверу. Когда ссылка возвращается на сервер она
продолжает существовать в виде стаба, не преобразуясь в локальную
• Удаленная загрузка классов
• Сформировать два «security policy file» – для клиента и сервера, в нем по codebase
указать привилегии для кода – откуда можно динамически подгружать код
Grant codebase “file:/….” {
Permission java.security.AllPermission
}
Поддерживаются файловые хранилища, FTP/HTTP сервера
• Запустить сервер и клиент, указав для каждого свойства
• Java.rmi.server.codebase – URL откуда брать недостающий код. Это будет на
сервере записано в стаб при создании ссылки на удаленный объект и клиент, его
использующий, обратится по данному URL за недостающим кодом
• Java.security.policy – расположение файла с политикой безопасности
• Сами классы никогда в составе RMI вызова не передаются вместе с
сериализованными данными
• Варианты развертывания
• Closed – все загружается только локально по classpath
• Server based – клиент загружается из codebase сервера вместе со всеми данными
• Client dynamic – основные классы из classpath, что-то из codebase, указанного
сервером
• Server dynamic – обратное предыдущему
• Bootstrap client / server – все загружается по сети, из classpath только
минимальный пусковик
• Сборка мусора
• Время жизни удаленной ссылки определяется системным свойством
java.rmi.dgc.leaseValue
• Если у объекта удалены все локальные и удаленные ссылки, то он традиционным
образом собирается
• Удаленный объект может реализовать java.rmi.server.Unreferenced, тогда его метод
void unreferenced() будет вызван при удалении последней удаленной ссылки
• Шифрование
• За счет использования специализированной фабрики сокетов
• Сервер
SSLContext ctx = SSLContext.getInstance(“SSL”);
KeyManagerFactory kmf = KeyManagerFactory(“SunX509”);
KeyStore ks = KeyStore.getInstance(keystoreType)
Ks.load(new FileInputStream(keystoreFile), password)
Knf.init(ks, password
Cts.init(kmf.getKeyManagers(), null,null)
SSLServerSocketFactory ssf = ctx.getServerSocketFactory();
ServerSocket ss = ssf.createServerSocket(port);
• Клиент
 SSLSocketFactory sf = SSLSocketFactory.getDefault ();
SSLSocket socket = sf.createSocket(host, port);

• Межсетевое взаимодействие
• Клиент за файрволом
• RMI запросы преобразуются в HTTP POST, данные идут в заголовок
• Устанавливается системное свойство http.proxyHost
• RMI сервер автоматически выделяет данные вызова из HTTP запросов
• И клиент и сервер за файрволом
• Основная проблема – порт сервера теперь не адресуем
• В HTTP заголовке теперь указывается порт сервера, на который надо отдать
запрос
• На серверном файрволе располагается java-rmi.cgi или сервлет, который
полученный HTTP запрос передает указанному порту сервера. При этом HTTP
вызов преобразуется в RMI. Обратно та же цепочка
• Недостатки
• Снижение производительности
• Сервер беззащитен, так как с помощью данного механизма можно направить
любой запрос на любой порт сервера
• Сервер не может сделать обратный вызов к клиенту
• Активация
• Основная идея – процесс активации rmid, в нем регистрируются модули активации,
создающие удаленные объекты, стабы от этих модулей регистрируются в реестре
под именами самих удаленных объектов.
• Rmid должен быть запущен после реестра и перед обращением любого клиента
• Регистрация модуля активации производится только один раз.
• Данные активации сохраняются внутри инсталляции rmid и все
автоматически стартует при ее запуске
• Зарегистрированная активация переживает крах как JVM активации, так и
JVM в которой развернут сервис
• В реальности что-то типа базы данных на файловом уровне
• Благодаря сервису активации можно спокойно перезапускать сервис, он будет
клиентом вызван и активирован повторно
• Активации подлежит класс, находящийся в группе активации. Для каждой группы
активации создается отдельная JVM. В случае необходимости она перезапускается.
Для группы активации определяется
• Ид группы
• Параметры запуска JVM и системные свойства
• Групповая политика безопасности, переданная через системные свойства
• Активация соответствует одному классу, для нее определяется
• Наименование класса активируемого сервиса
• Должен реализовывать Activatable и иметь специальный конструктор, в
который передаются
• ActivationID – ид активированного объекта
• MarshalledObject – данные инициализации
• ИД группы активации – если не запущена, то будет стартована
• Codebase откуда грузить класс
• Данные инициализации объекта в виде MarshalledObject. Его отличие от просто
сериализованного класса – наличие внутри информации откуда грузить класс
реализации
• Режим старта объекта – по запросу (дефолтный) или при старте сервиса
инициализации
 • Этапы работы
• Создание описания группы активации
ActivationGroupDesc(Properties, CommandEnvironment)
• Регистрация группы активации и получение ИД группы
ActivationGroupID grid = ActivatioGroup.getSystem().registerGroup(groupDesc)
• Создание активатора объекта
MarshalledObject data = new MarshalledObject(fileName)
ActivationDesc desc = new ActivationDesc(grid, implClass, implCodeBase, data)
• Регистрация активатора объекта
Remote stub = Activatable.register(desc)
LocalRegistry.getRegistry().rebind(name,stub)
• Этапы активации
• Клиент получает из реестра стаб активации и вызывает метод
• Стаб проверяет запущен ли сервис, вызывав его
• Если да – вызывает операцию
• Если нет
• Вызывает систему активации, используя ActivatioId внутри себя
• Если группа не запущена – стартует
• Создается и инициализируется объект
• Вызывает функцию сервиса
• Дополнительные особенности
• Система активации держит сервисный объект, не позволяя ему собраться даже
при отсутствии клиента. Значит надо опускать объект вручную через
Activable.incative(activationId). На практике надо реализовывать отдельную нить,
отслеживающую таймаут для сервиса
• Можно удалить активацию через Activable.unregister(activationId).
• Можно не расширять класс Activable, а пользоваться его статическими методами
типа register и т.д.
• Можно при активации объекта за счет обращения к ActivationSystem получить
экземпляр ActivationMonitor через который отслеживать события
• Объект активирован
• Объект деактивирован
• Группа деактивирована

RMI и CORBA
• Общая идея
• Три транспорта – JRMP, RMI-IIOP, CORBA
• RMI клиент – к RMI и RMI-IIOP серверам
• RMI-IIOP клиент
• к RMI-IIOP и RMI серверам
• к Corba серверам с ограничениями
• CORBA клиент – к RMI-IIOP и CORBA серверам
• RMI-IIOP компонент
• может переключаться между RMI-IIOP и JRMP просто за счет системных
параметров, без необходимости переписывания кода
• можно вывесить поддерживая JRMP и RMI-IIOP одновременно
• Есть специальный вариант – Java IDL
• Альтернатива RMI-IIOP
• Доступ к Corba объектам без ограничений. Идеален для доступа к уже
имеющимся сервисам
• Код требуется переписывать
 • Итого: если пишем сервис с нуля - RMI-IIOP, если стучимся к уже имеющимся -
Java IDL
• Переход с JRMP на RMI-IIOP
• Remote => PortableRemoteObject
• Registry => InitialContext, так как теперь используем JNDI
• При использовании rmic надо через ключи указывать специфику
• Реестр – tnameser.exe
• Полученный из InitialContext объект надо приводить к типу через
PortableRemoteObject.narrow

недостатки и расширения
• Недостатки
• Только в рамках одного административного домена, так как нет авторизации и
аутентификации. Не передается транзакционный контекст
• Можно сделать свой бизнес делегат (а его все равно, так или иначе делать), в нем
наименование вызываемого метода и параметры запаковать и вместе с ид
транзакции отдать обертке серверного объекта, которая установит контекст и
через отражение вызовет метод
• Можно использовать свои фабрики, осуществляющие сетевое взаимодействие и
подмешивать данные прямо в поток.
• Не ограничено число нитей, выделенных под обработку клиентских запросов, нет
их повторного использования
• Можно воспользоваться сходными технологиями – BEA WebExpress
• Можно сделать вызов удаленного метода коротким, только добавляя задание в
очередь – шаблон Command
• Из очереди их извлекать пулом нитей – обработчиков в соответствии с
заданной политикой
• Задания хорошо делить по приоритету, например логирование отправлять
через медленные задания
• На клиенте особенно полезно, потому как изменять свойства объектов
интерфейса можно только в нити-обработчике Swing
• Расширение – JERI – Java Extenxible Method Invocation
• Появилась в июне 2003 года, в стандарт не вошло, есть только Sun реализация
• Возможен экспорт объекта на основе декларативно задаваемой конфигурации,
включающей различные реализации создания Exporter. Всего порядка десятка
разновидностей
• На вызываемое извне поведение объекта могут накладываться любые
ограничения
• Вызов может осуществляться через различные протоколы – JRMP, IIOP, HTTP,
SSL
• к вызову могут подмешиваться транзакционный контекст или токен
безопасности
• Определяется три слоя, через которые проходит вызов от клиента к серверу. За счет
конфигурации реальные компоненты, работающие на каждом уровне, могут быть
переопределены прозрачно для приложения
• Уровень вызова, InvocationHandler для клиента и InvocationDispatcher. На данном
уровне производится сериализация / десериализация клиента и вызов серверного,
компонента
• Уровень маршрутизации, ObjectEndpoint и RequestDispatcher. Работа со стабами,
поиск подходящих серверных объектов, распределенная сборка мусора
• Уровень транспорта, Endpoint и ServerEndpoint. Преобразование вызова в
транспортный формат и работа с сетью
 • Принципы ускорения RMI приложений
• Параметр TCP протокола TcpWindowSize – увеличить для хорошей сети, уменьшить
для ненадежной и Интернет
• Управление сборкой мусора - в идеале должна запускаться, когда использована вся
куча. На самом деле RMI запускает сборку сам каждые 60 секунд. Управляется
параметрами sun.rmi.dgc.client|server.gcInterval. Имеет смысл увеличить сообразно
размеру кучи
• Для многопроцессорной системы запускать по JVM на каждом процессоре и
обмениваться данными через RMI
• Самое серьезное – делать вызовы как можно более большими. Разница между
передачей массива целиком и по частям может достигать сотен и тысяч раз
• Отказаться от встроенного механизма сериализации – он использует отражение и
тормозит. Реализовать интерфейс Externalizable и все писать в поток ручками.
Вложенные объекты, в том числе коллекции обрабатывать самому
• Примерно четверть выигрыша
• Код не устойчив к изменениям структуры классов во время разработки.
Добавление / удаление полей требует согласованного переписывания процесса
чтения / записи
• Когда используются интерфейсы и наследники не ясно что создавать из потока
• Когда один объект используется несколькими сложно восстанавливать данные
• Использовать null вместо дефолтных значений. Большие объемы внедренных
данных имеет смысл считывать другими инструментами – например через общую
базу данных
• По минимуму использовать реестр – получать из него только один объект, например
DAO, а все остальные объекты уже непосредственно через данный
• Кэширование данные – использовать вместо непосредственно стабов «умные»
прокси
• У объекта делается просто интерфейс и удаленный интерфейс
• Сервис, возвращающий удаленный объект, обертывает стаб в сериализованую
умную прокси
• Прокси осуществляет, например
• кэширование данных которые как известно серверу не меняются после
получения объектом клиента
• подписывается на изменения отдельных свойств на сервере и получает
обновления по частям
• осуществляет пред и пост обработку клиентских запросов, перед передачей
их стабу и далее серверу. Например, кэширует результаты вычислений

EJB
Различные замечания
• Вместо стаб / скелетон используются термины stub/tie
• Используются термины:
• Сессионные - «transient»
• Stateful
• могут хранить “conversational state”
• не возможен пулинг
• stateless
• не могут
• возможен пулинг, лучше поддерживают scalability за счет совместного
обслуживания большого числа клиентов
 • лучше производительность – нет необходимости пассивировать /
активировать
• сущности - «persistence»
• Достижимость scalability, необходимой для поддержки растущих требований по
нагрузке, обеспечивается возможностью разделить приложений на основе EJB на
необходимое количество серверов

Messaging
Общие замечания
• Достоинство приложений на основе обмена сообщениями – они событийно управляемы
• При использовании синхронных вызовов, также упоминаемых как “blocking call”
• По мере увеличения нагрузки требуется большая полоса пропускания от сети,
следовательно критично добавление нового железа
• Реализация проще
• Более чувствительно к проблемам железа, БПС и сети. Если хотя бы одна сторона не
активна – взаимодействие установлено быть не может
• Сообщение должно быть подтверждено перед выборкой следующего
• Поддерживается ТОЛЬКО посредством JMS
• Типовые сценарии
• Клиенту требуется результат обработки сообщения для продолжения
выполнения операции
• При использовании асинхронных вызовов, также упоминаемых как “nonblocking call”
• Лучше адаптируется к изменению нагрузки, особенно в части сглаживания пиковой
нагрузки
• Реализация сложнее
• Легче переживает временные отказы компонентов. Взаимодействие возможно при
временной остановке одной из сторон. Информация не теряется, но ее доставка
откладывается
• Типовые сценарии
• Когда ответ вовсе не требуется или требуется не сразу
• Планируется обработка большого количества сообщений, возможно с пиками
обслуживания
• Железо должно использоваться более эффективно
• Поддерживается как посредством JMS, так и посредством MDB
• Основные механизмы взаимодействия
o point-to-point – обмен сообщениями «один к одному»
 примеры - взаимный обмен сообщениями, получение транзакции из
другой системы, отправка заказа на обработку в другую систему, supply-
chain операция
 подписчик гарантированно получает сообщения в том же порядке, в
котором они были отправлены
 можно просматривать сообщения вперед, например для определения их
количества, но потреблять можно только в порядке FIFO
o publish-subscribe (push-based model) – обмен сообщениями «один к многим»
 примеры – многоадресная рассылка в организации, рассылка информации
заинтересованным потребителям, причем перечень заранее не известен,
рассылка запросов на конкурентную обработку данных
 Подписка может быть постоянной и временной (по умолчанию)
• При временной получает сообщения только пока активен
 • При постоянной получает и те сообщения, которые пришли в
момент неактивности – сильно нагружает систему обмена
сообщениями
• Использование
o Для распределения транзакции между многими системами требуются технологии
JMS и EJB вместе
o Самый легкий способ интеграции несовместимых между собой систем
o Распределение сценариев:
 Рассылка сообщений одно и много адресная, интеграция несовместимых
систем – JMS
 Вызов бизнес логики и работа с данными – EJB
 Реализация распределенных транзакций между несколькими системами –
EJB + JMS

Основные компоненты
• JMS provider – поставщик сервиса, обернутый стандартным JMS API, по нативному
протоколу обменивается с middleware обмена сообщениями
• Объекты администрирования, создаваемые администратором при помощи нативных
средств и доступные приложению через JNDI по имени
o Destination – адресат сообщения, просто интерфейс маркер
 может быть Topic и Queue
• добавляется работа с именем
• в том числе временные версии, добавляется возможность удаления
 сами по себе функциональности не реализуют, это просто адреса. Для
получения и отправки сообщений нужны сответственно Consumer и
Producer
 получаются в контейнере через @Resource. Вне контейнера через JNDI
o ConnectionFactory – интерфейс вендорно зависимой фабрики соединений с БПС
 может быть соответственно TopicConnectionFactory и
QueueConnectionFactory
 получаются в контейнере через @Resource. Вне контейнера через JNDI
• Сообщения
o Когда сообщение доставляется повторно провайдер устанавливает
соответствующий флаг
o Режимы подтверждения сообщений
 Когда прием транзакционный, то подтверждение отправляется в момент
фиксации транзакции
 AUTO_ACKNOWLEDGE – в момент выхода клиента из метода
получения сообщения или когда onMessage слушателя благополучно
завершается
 CLIENT_ACKNOWLEDGE – клиент должен ручками вызвать метод
подтверждения на сообщении. В MDB не поддерживается
 DUPS_OK_ACKNOWLEDGE – то же самое, что и
AUTO_ACKNOWLEDGE, но провайдер экономит ресурсы отсылая
подтверждения по мере возможности. В результате сообщения могут
доставляться повторно
o Структура сообщения
 Заголовок - обязательный элемент, содержит необходимую информацию
для идентификации и доставки сообщения
• JMSMessageID
• JMSDeliveryMode
 o PERSISTENCE – хранится в базе до тех пор, пока все
получатели его не получат, доставляется только раз
o NON_PERSISTENCE – хранится только в памяти, может
быть потеряно, доставляется не больше чем раз
• JMSExpiration – время жизни, 0 – не ограничено
• JMSPriority – приоритет доставки, по возможности, то есть не
гарантируется, по умолчанию = 4
• JMSRedelivered – флаг повторной доставки
• JMSTimestamp – время, проставляется провайдером при отправке
• JMSCorrelationID – в ответ на какое сообщение сформировано
данное
• JMSReplyTo
 Свойства – опциональный элемент, содержит значения именованных
свойств.
• Свойства могут быть как предопределенные – как правило,
устанавливаемые провайдером в момент отправки сообщения и
имеют JMS_ префикс, так и локальные для приложения
• Значения элементов заголовка и свойств могут использоваться
посредством MessageSelector для фильтрации получаемых
сообщений
 Тело – опциональный элемент, поддерживаются следующие форматы –
ByteMessage, MapMessage (имена – строки и примитивы), ObjectMessage,
StreamMessage, TextMessage (особенно удобен для XML сообщений)
• Сессия – абстракция сеанса работы, служит для
o поддержки транзакций, то есть объединения сообщений в группы, которые могут
быть в целом отправлены / получены или сброшены. В случае приема
сброшенные сообщения доставляются повторно.
o Использования специфического режима подтверждения
o Соответственно разделяются на TopicSession и QueueSession
• Connection – абстракция физического соединения с подсистемой обмена сообщениями,
может быть TopicConnection и QueueConnection
• средство отправки сообщений - MessageProducer
o TopicPublisher
o QueueSender
• средство получения сообщений –
o MessageConsumer
 TopicSubscriber
 QueueReceiver
o QueueBrowser – средство просмотра сообщений в очереди без получения их. Для
работы с топиками НЕ подходит
o MessageListener – средство асинхронного получения сообщений
• Средство получения ошибок - ExceptionListener

Обзор API - пакет javax.jms

o Изначально было две ветки API – одно для очередей, одно для топиков. Сейчас
посредством наследования практически у всего есть общие предки
o ConnectionFactory
 Получается из контейнера через @Resource или просто посредством
JNDI. Создание и конфигурирование реального компонента стандартом не
определяется
 Connection createConnection() – создание соединения, есть версия,
которой можно передать логин и пароль
o Connection – физическое соединение с JMS провайдером
 Thread-safe класс
 createSesstion(transMode, acknowledgeMode) – соновной метод для
создания сессии
 transMode – true/false работа в рамках сессии
 acknowledgeMode – режим подтверждения приема сообщений,
поддерживаются
 close() – необходимо закрывать в конце работы
 get/set ExceptionListener – регистрация слушателя сообщений об
ошибках. Должен реализовывать метод onException(JMSException exception),
получающий исключение, содержащее код / текст ошибки и ссылку на
родительское исключение
 getConnectionMetaData – получение информации о провайдере – две
версии JMS, наименование провайдера, две версии провайдера, набор свойств в
виде перечисления, зависящий от провайдера
 get/set ClientId – работа с ИД клиента для осмысленности информации в
БПС обмена сообщениями
 start / stop – запуск / остановка процесса получения сообщений
o Session – сессия отправки / получения сообщений
 НЕ Thread-safe класс, сеанс и контекст получения и отправки сообщений
 Отправка сообщений
 createXXXMessage – создание сообщения
 MessageProducer createProducer(destination) – создание объекта для
отправки сообщения
 Получение сообщений
 QueueBrowser createBrowser(Queue, [messageSelector]) – создание
обозревателя очереди. Тот может вернуть перечисление сообщений в
очереди в порядке их ожидаемого получения
 MessageConsumer createConsumer(Destination, [messageSelector,]
[NoLocal]) – создание синхронного получателя сообщений
• messageSelector - SQL92 совместимым выражением для отбора
сообщений
• NoLocal – запрет на получение собственных сообщений в случае
топика
 get/setMessageListener – работа с асинхронным слушателем сообщений,
• должен реализовывать интерфейс MessageListener, содержащий
единственный метод void onMessage(Message)
• получение сообщений начинается в момент start() метода на
Connection
 Постоянная подписка на сообщения топика
 TopicSubscriber createDurableSubscriber(Topic, name,
[messageSelector], [NoLocal]) – регистрация постоянного синхронного
подписчика на сообщения топика, TopicSubscriber – наследник
MessageConsumer
 unsubscribe(name) – дерегистрация постоянного подписчика на
сообщения топика
 Администрирование
 TemporaryQueue|Topic createTemporaryQueue|Topic() – создание
временной очереди / топика
• Наследник соответствующего класса Queue|Topic
o Добавляет единственный метод delete()
o Можно получить имя и toString()
  Queue|Topic createTopic| Queue (Name) – создание именованной очереди
/ топика
 commit() – если сессия транзакционная, то отправка сообщений
 close() – выполняет и commit тоже, необходимо закрывать в конце работы
o MessageProducer – отправитель сообщений
o Наследники - TopicPublisher, QueueSender
o Основной метод – отправка сообщения - void send([Destination], Message,
[deliveryMode, priority, timeToLive])
 Одно сообщение может быть отправлено несколько раз в разные адреса
o Методы глобальной для отправителя установки и считывания deliveryMode,
priority, timeToLive
o При создании отправителя Destination задается, поэтому вменить дефолтный
нельзя, но можно отправить в другое назначение
o MessageConsumer – синхронный получатель сообщений
o get/setMessageListener – работа с асинхронным слушателем сообщений
o getMessageSelector – работа с селектором сообщений
o Message receive[NoWait](long timeout) – синхронное получение сообщение,
возможно с таймаутом или без ожидания, тогда может вернуть null

Шаблоны интеграции
Базовые шаблоны
o Каналы и сообщения
o Каналы и фильтры
o Маршрутизаторы
o Преобразователи
o Конечные точки

Каналы
o «точка-точка» канал (Point-to-Point Channel) – средство доставки сообщения
только одному получателю.

Даже в том случае, если у канала зарегистрировано несколько

получателей.
 Координировать их работу между собой не надо
 они могут конкурировать за получение – средство масштабирования
нагрузки
o «публикация-подписка» канал (Publish-Subscribe Channel) – средство
доставки сообщения каждому из группы заинтересованных получателей
  Реализация шаблона «наблюдатель»
 Каждый из подписчиков получает сообщение только один раз, затем оно
удаляется из топика
 Средство отладки – «прослушивание» канала, имеет негативное
последствие – небезопасность
 В некоторых системах можно подписываться на каналы используя
шаблон наименования топика
 Возможна постоянная подписка на сообщения, но она сильно загружает
систему
o Канал типа данных (Datatype Channel) – средство отправки обработчику
данных определенного типа

 Получатель заведомо знает какие данные он ожидает по данному каналу.

 Недостаток
• отправитель должен содержать логику разбрасывания сообщений
по каналам
• много каналов – тяжело для системы
 Простейший вариант, альтернативы:
• ИД формата в заголовке сообщения – много Case в продолжении
• сообщение с командой – проблема с безопасностью
• мультиплексирование канала
o за счет присоединения избирательных потребителей
o за счет маршрутизатора на основе содержимого в несколько
других каналов
• за счет диспетчера сообщений, обслуживающего ряд потрбителей
o Канал недопустимых сообщений (Invalid Message Channel) – способ
компоненту обработать сообщение, которое имеет недопустимый формат

 Журнал записи ошибок для администратора системы, обработчик –

подсистемы логирования или уведомления
 Следует отличать от сообщений, недопустимых с точки зрения логики
обработки. Например, требования удалить несуществующую запись.
Такое сообщение в канал недопустимых направляться не должно
 Сообщения данного канала НЕ должны быть проигнорированы
o Канал недоставленных сообщений (Dead Letter Channel)
 Провайдерно-зависимая фича, так как подобные сообщения выявляются
только системно.
• Это отличие от предыдущего случая – недопустимые сообщения
отправляются в канал на основании решения прикладного кода
• В принципе у каждого участника системы на машине должен быть
собственный подобный канал
 Возможные причины:
• Неправильно настроенные получатели
• Внезапно удаленный канал в котором еще есть сообщения
• Время доставки истекло
• Ошибка в полях заголовка
 Использование – запись в журнал лога, уведомление администратора
и/или разработчика
o Гарантированная доставка (Guaranteed Delivery) – обеспечение доставки
сообщения даже в том случае, когда система накрывается

 Передача с промежуточным хранением - достигается сохранением

сообщения в базе данных локальной, для каждого участника системы.
 Увеличение надежности системы, но снижение производительности и
повышенные требования к ресурсам, особенно если сообщений много
 Сообщения о событиях, к примеру, можно не хранить. А вот сообщение –
заказ хранить надо
 Рекомендуется отключать на время тестирования и отладки. В противном
случае каждый раз при запуске надо будет чистить все очереди
 Как правило гарантированная доставка включается вместе с
транзакционностью
o Адаптер канала (Channel Adapter) – способ подключить приложение к
системе обмена сообщениями, обеспечить отправку и прием сообщений

 Играет роль клиента для системы. Как правило по мере возможности

реализуется транзакционный клиент
  Использует пользовательский интерфейс (прочесывание экрана), API или
модель данных системы для формирования сообщений или обработки
подступающих сообщений
 Наиболее удобный способ, требующий минимум от системы – работа с
БД, особенно удобно, когда можно установить собственные триггеры
 Использование стандартных для приложения адаптеров канала,
поставляемых вендором, требует дальнейшей трансляции сообщений в
каноническую модель данных
 Могут быть однонаправленными и двунаправленными, располагаться на
том же СВТ, что и система, или на отдельном
 Могут быть адаптерами данных и адаптерами метаданных. Последние
используются для настройки трансляторов сообщений и
администрирования системы
o Мост обмена сообщениями (Messaging Bridge) – интеграция между собой
нескольких систем обмена сообщениями

 Единственный способ сшить две системы обмена сообщениями – сшивать

каналы. Поэтому мост – набор адаптеров канала
• связывающих отдельные каналы попарно
• осуществляющих преобразование форматов перекидываемых
сообщений
 альтернатива – подписать каждого клиента на все подсистемы обмена
 мост является клиентом КАЖДОЙ подсистемы обмена
 встречаются стандартные мосты, предоставляемые вендорами для связи
между лидерами отрасли
o Шина сообщений (Message Bus) – средство обеспечения независимости
интегрированных приложений в процессе их согласованной работы

 Шина сообщения это комбинация

• Общей или канонической модели данных
• Общего набора команд. Каждая команда должна быть понятна
всем участникам процесса. Средства – «сообщение с командой»
или «канал типа данных»
• Инфраструктуры обмена сообщениями, доведенной так или иначе
до каждой системы. Как правило в составе инфраструктуры
реализуются
o маршрутизаторы команд
o каналы «публикация-подписка»
 o адаптеры для каждого из приложения или «активаторы
службы»
 пример сервис ориентированной архитектуры – SOA.
• Каждой службе соответствует как минимум один канал получения
запросов и как минимум один канал ответов.
• Служба доступна для всех остальных компонент, подключенных к
шине

Сообщения
o Сообщение с командой (Command Message) – использование сообщения для
вызова команд другого приложения, аналог шаблона «команда»

 Особенно удобно для организации асинхронного вызова API

 Каким либо специальным типом сообщения не поддерживается. Если на
обоих сторонах Java, то лучше использовать ObjectMessage, иначе
TextMessage с XML внутри
 SOAP может реализовываться на основе БПС обмена сообщениями
 Часто применяется с шаблоном «запрос-ответ», возвращается результат
выполнения команды
o Сообщение с данными документа (Document Message) – использование
обмена сообщениями для передачи данных между приложениями

 Порция данных, что с ней делать решает получатель

 Плюсы и отличия
• Больше контроля над процессом, чем при передаче файлов.
• Не требуется создания структуры в БД.
• В отличии от RPC получателю не диктуется что с ними делать. С
точки зрения отказоустойчивости лучше
 Лучше с точки зрения безопасности – данные видит только получатель
 Одновременно с передачей данных инициируется операция их обработки
 Во многом напоминает сообщение о событии, но
• главной частью сообщения является не само уведомление, а
данные
• Часто используется гарантированная доставка, срок действия
практически не используется
 Как правило используется передача «точка-точка», реже
широковещательная
 Часто применяется с шаблоном «запрос-ответ», возвращается результат
обработки документа
o Сообщение о событии (Event Message) – передача уведомления о событии из
одного приложения в другое, шаблон «наблюдатель»
  Как правило, используется широковещательная передача, реже «точка-
точка»
 Данные менее значимы, зачастую даже их просто нет. Важна
своевременность доставки – часто используется срок действия
 Гарантированная доставка используется редко, получатель может просто
игнорировать большинство сообщений. Также редко используется
постоянная подписка
 Сообщение должно быть доставлено и обработано как можно быстрее.
 Модели использования
• Проталкивание – в сообщении и уведомление, например, об
изменении данных, и сами данные. Более эффективна, когда
данные интересуют большинство наблюдателей
• Вытягивание, набор из трех сообщений – уведомление об
обновлении данных, запрос данных, документ с данными.
o Если данные интересуют не всех, то меньше объем
передаваемых данных
o Сложнее структура каналов, больше сообщений и
интенсивность трафика
o Запрос – ответ (Request-Reply) – возможность для отправителя получить
ответ на полученное сообщение

 Классическая модель предусматривает асинхронную передачу только от

отправителя получателю, каналы в принципе однонаправленные
 Шаблон может использоваться отправителем как с очередями, так и с
топиками, в зависимости от того, должно ли сообщение быть обработано
кем-то одним или всеми
 В отличии от канала отправления, канал получения может быть только
«точка-точка», так как отправитель один
 Два основных подхода
• Синхронная блокировка – отправитель высылает сообщения,
становится опрашивающим потребителем (polling consumer) и
заблокировавшись ждет результата выполнения.
o Проста в реализации
o Если отправитель выйдет из строя и перезапустится, то ему
будет сложно восстановить поток выполнения
o В каждый момент времени может существовать только один
необработанный запрос
 •Асинхронный обратный вызов
o Один поток отправителя высылает сообщение, другой
прослушивает канал ответов. В сообщении содержится
ссылка на канал ответов, в который получатель публикует
результат обработки сообщения
o Легко перезапускаться
o Одновременно можно ожидать и обрабатывать результат
нескольких вызовов
o Сложность – при обработке результата надо
восстанавливать контекст вызова, в котором было
отправлено исходное сообщение
 Типовые сообщения
• RPC вызов - сообщение с командой, в ответ приходит документ с
данными или исключение
• Запрос данных – сообщение с командой, в ответ результирующий
набор данных в виде одного или нескольких сообщений
• Уведомление / подтверждение – в ответ часто запрос на получение
дополнительных данных
 Способы связи между вопросом и ответом
• В исходном сообщении должен содержаться обратный адрес в
JMSReplyTo.
o Часто это временная очередь, создаваемая отправителем на
время своей жизни. При перезагрузке отправителя очередь
очищается, то есть гарантированная доставка не
поддерживается
o При синхронной отправке – получении для каждого
отправленного сообщения создается отдельная очередь
ответов с получателем. Требуется много ресурсов
• В сообщении с ответом должен содержаться идентификатор
корреляции - JMSCorrelationID
o Обратный адрес (Return Address) – уведомление получателя о месте, куда
надо направить ответ на сообщения

 Можно задать канал ответов прямо в коде получателя

• но это снижает гибкость системы, а также лишает возможность
получателя обслуживать много инициаторов запроса
• возможно, что результат обработки запроса интересует не
отправителя, а другой (следующий) компонент
• у инициатора может быть несколько процессоров результатов
обработки, например в зависимости от типа результата
 логика определения дальнейшего обработчика результата выносится из
получателя сообщения в отправителя за счет использования поля
 JMSReplyTo. Как правило сообщение-ответ связывается с сообщением-
вопрос за счет идентификатора корреляции – JMSCorrelationID
o Идентификатор корреляции (Correlation Identifier) – способ логической
связи между собой сообщений вопроса и ответа

 Имеет смысл только при асинхронном типе взаимодействия через

сообщения
 Другие варианты
• Отправитель не делает другого вызова, пока не получит результата
предыдущего – проблемы с производительностью
• Предполагать, что ответы приходят в том же порядке, что и были
сделаны вызовы – порядок доставки не гарантирован, обработка
каждого запроса требует различное время
• Не использовать ответы на запросы вовсе – однонаправленный
канал передачи информации
 Выбор ИД корреляции
• равен ИД сообщения, на который выслан ответ, помещается в
заголовок. Проблема – если далее в канале используется отвод
сообщений для анализа, то ИД сообщения может в промежутке
между отправителем и получателем измениться. Тогда ответ по ИД
корреляции не будет соотноситься с исходным сообщением.
• идентифицирует исходную бизнес транзакцию, которой
предназначен ответ. Если ИД транзакции надо скрывать, то
генерируем ИД исходного сообщения, а ИД транзакции
прикапываем в его контексте
 Ответов может быть несколько
• Все ответы ссылаются на один запрос
• На запрос ссылается только первый ответ, а остальные друг на
друга по цепочке
 Последовательность вопросов – ответов может включать несколько
этапов, тогда следующий вопрос будет ссылаться на предыдущий ответ
 Часто используется совместно с указанием в запросе обратного адреса,
которому надо выслать ответ
o Цепочка сообщений (Message Sequence) – передача посредством сообщений
сколь угодно большого объема данных

 Ограничения на объем сообщения зависит от вендора, как правило есть

некоторый оптимум между объемом и производительностью БПС
  Большой объем данных передается последовательностью, в каждом
сообщении последовательности – ИД цепочки, ИД позиции, Индикатор
длинны или конца последовательности
 Для отправки или приема последовательности лучше пользоваться
транзакционным клиентом.
• Вся цепочка обрабатывается в рамках одной транзакции.
• При этом во многих системах гарантируется еще и порядок
сообщений в рамках одной транзакции – облегчение работы по
восстановлению данных
 Часто ИД цепочки является одновременно и ИД корреляции
 Несовместимо с конкурирующими потребителями или диспетчером
сообщений – все части должны собираться в одном месте. Поэтому
используется только с каналом «точка-точка»
 Вместо цепочки можно использовать шаблон квитанции: данные в базу,
ид от базы в сообщение. При этом обе системы должны иметь общий
доступ в базу
 Может реализовываться разветвителем совместно с агрегатором,
особенно когда между ними данные надо протолкнуть в канал с
ограничениями
o Срок действия сообщения (Message Expiration) – способ уведомления
получателя о том, что сообщение имеет ограниченный срок действия

Период действия сообщения зависит от бизнес специфики приложения,

которому необходимы данных
 В зависимости от настройки системы сообщение либо просто исчезает,
либо передается в канал недоставленных сообщений
 Срок действия может быть абсолютным и относительным, для больших
систем необходимо учитывать временные пояса, летнее время и прочие
особенности локали
 В схеме «публикация-подписка» кто-то может получить, а кто-то нет
 В схеме «запрос-ответ» отправитель может никогда и не узнать, что
сообщение до получателя не дошло. Иногда такая ситуация требует
специальной обработки, например для случая, когда ожидается ответ с
блокировкой отправителя
o Индикатор формата (Indicator) – способ проектирования формата
сообщения с учетом изменений в будущем
 Даже если используется единая модель данных, то она меняется. При
этом:
• Приложения переходят на новые версии форматов не синхронно
• В каналах могут оставаться сообщения в старой версии формата
 То есть одновременно неизбежно используется несколько версий
форматов данных.
  Формат данных либо зашивается в код, либо описывается схемой в
нотации, известной всем приложениям
 В сообщение встраивается специальное поле «индикатор формата»,
которое может задаваться следующими путями:
• ИД версии и каждое приложение в себе хранит описания всех
необходимых форматов
o Нет необходимости использовать общесистемный
репозитарий дескрипторов форматов
o Но каждое приложение теперь должно знать какому ИД
соответствует какой формат
• Внешний ключ, например URL, на документ с описанием формата.
Описание может быть очень подробным и храниться в едином
месте, но каждой приложение должно иметь туда доступ и оттуда
его извлечь
• Описание формата зашивается в само сообщение. Сообщение
становится самодостаточным, но сильно увеличивается объем.
Редко меняющиеся данные будут отправляться и приниматься
повторно

Маршрутизация сообщений
o Общая классификация
 Простые маршрутизаторы
• Одновременная обработка одного сообщения за раз без сохранения
состояния. Можно запускать по нескольку экземпляров каждого
маршрутизатора для ускорения обработки
o Одно сообщение на выходе
 Ноль или одно сообщение на выходе – «фильтр
сообщений»
 Ровно одно сообщение на выходе – «маршрутизатор
на основе содержимого»
o Несколько сообщений на выходе
 Параллельная обработка сообщений – «список
получателей»
 Последовательная обработка сообщений –
«разветвитель»
• Одновременная обработка нескольких сообщений за раз с
сохранением состояния
o Меньшее количество сообщений на выходе – «Агрегатор»
o То же количество сообщений на выходе –
«Преобразователь порядка»
 Сложные маршрутизаторы
• Параллельная обработка
o Разделение сообщения – «обработчик составного
сообщения»
o Широковещательная рассылка – «рассылка - сборка»
• Последовательная обработка
o Предопределенная линейная – «карта маршрутизации»
o Несколько вариантов – «диспетчер процессов»
o Маршрутизатор на основе содержимого (Content-Based Router) – доставка
сообщения в ситуации, когда реализация единой логической функции
распределена между несколькими компонентами системы, предиктивная
маршрутизация
  Централизованная логика распределения сообщений по компонентам,
вынесенная из отправителя
• Плюсы
o легко добавлять варианты логики
o централизованная точка контроля, легко отлаживать и
мониторить
o более контроля, безопаснее с точки зрения передачи
конфиденциальных данных
• Основной минус - менее легко расширять список получателей
o маршрутизатор должен знать об особенностях всех систем
получателей, добавление / удаление получателя требует
внесения изменения в маршрутизатор
o Компенсация недостатков – более сложный «динамический
маршрутизатор», принимающий от подписчиков
уведомления об их потребностях
• Образуется узкое место через которое идет вся информация, плюя
или минус в зависимости от условий
 Альтернатива – «публикация – подписка», с подписчиками на основе
фильтрации
• Легко добавлять новых получателей
• Каждое приложение само решает какие сообщения обрабатывать,
логика маршрутизации распределена
• Основной недостаток – одно сообщение легко может быть
обработано несколькими системами или не обработано не одной
• Трафик и расходы на обработку растут
 Альтернатива – цепочка ответственности
• Плюс – видны не обработанные сообщения, каждое сообщение
будет обработано не более одного раза
• Велики издержки на обработку сообщения
• Системы должны частично знать друг о друге, скорее всего
потребуется модифицировать их код
 Лучше всего выносить набор правил маршрутизации в декларативно
определяемую конфигурацию
 Часто используется для бизнес транзакций, например при обработке
заказов
 Более эффективен при работе с очередями сообщений и если среда
ориентирована на передачу информации «точка-точка», например в
интернет
o Фильтр сообщений (Message Filter) – позволяет каждому получать только
интересующие его сообщения, реактивная фильтрация

 Позволяет минимизировать количество каналов в системе

 Простота подключения потребителей к системе – настраивать нужно
только подключение его самого, можно не вмешиваться в код самого
компонента
 Минус – если число и свойства получателей часто меняется, то вносимые
изменения размазываются по системе
 Частный случай маршрутизатора на основе содержимого с двумя
каналами: к компоненту и в мусорную корзину
 Отличие от селектора при подписке (встроенный в клиента фильтр
сообщений) – клиент НЕ потребляет сообщение, минимизируется трафик
и расходы на прием / распознавание / анализ сообщения
 Фильтр может быть с сохранением состояния, например передавать
сообщение только в том случае, если какой-то параметр изменился более
чем на пороговую величину
 Часто используется для рассылки уведомлений о событиях или
информационных сообщений
 Более эффективен при работе с топиками, а также если среда
предусматривает возможность широковещательной передачи
информации, например по диапазону IP или если БПС позволяет
осуществлять подписку в иерархии наименований
o Динамический маршрутизатор (Dynamic Router) – способ избавить
маршрутизатор от зависимостей от получателей

 Отличие в наличии специализированного управляющего канала и базы

данных конфигурации
 Устойчивость к выходу из строя
• Либо база конфигурации постоянного хранения
• Либо при старте отсылать широковещательное сообщение всем
потенциальным потребителям с просьбой выслать правила
маршрутизации
 Правила маршрутизации отдельных потребителей могут противоречить
друг другу, необходима стратегия разрешения конфликтов
• игнорировать правила, противоречащий уже имеющимся.
Содержание базы непротиворечиво, но поведение становится
зависимым от порядка старта потребителей и в общем случае не
предсказуемым
• отправлять сообщение первому получателю с подходящими
критериями. Та же неопределенность
• отправить всем получателям с подходящими критериями. В
пределе превращает маршрутизатор в список рассылки и нарушает
принцип единственности адресата сообщения
 сложность решения и его отладки
 используется в SOA системах, ориентированных на доступ к службам.
Сообщение в адрес службы отправляется динамическому
 маршрутизатору, а тот на основании базы определяет расположение
службы и передает сообщение
 Сходный шаблон – «клиент-диспечер-сервер», отличие в более
интеллектуальном распределении запросов по серверам
o Список получателей (Recipient List) – рассылка сообщения согласно списку
получателей

 Список может формироваться как отправителем, так и выделенным

компонентом, в котором локализуется логика распределения информации.
В любом случае имеем две части шаблона
• Формирование списка получателей. Может браться как из
внешнего хранилища, так и из самого сообщения. В последнем
случае список из рассылаемого сообщения удаляется
• Собственно распределение сообщения
 Аналог списка рассылки в электронной почте, позволяет более динамично
варьировать перечень получателей, чем другие шаблоны
 В отличии от шаблона «публикация-подписка» контроль над перечнем
реальных получателей не у получателей, а у отправителя.
• Поведение не зависит от «честности» получателей
• Более безопасно, позволяет внедрять централизованную логику
контроля прав потребителей на получение информации
 Альтернатива
• можно обязать самого отправителя посылать по одному
сообщению каждому получателю
o Тесно свяжет отправителя с инфраструктурой системы в
целом
o Невозможно, когда код отправителя не изменяем
• Публикация / подписка с фильтром сообщений
o Проще реализация и управление, но менее
централизованный контроль
o Чаще используется для уведомлений, чем для бизнес
информации
 Надежность рассылки: требует, во-первых, рассылки всем или никому, во-
вторых, получатели могут потребить свои сообщения только после
выполнения успешной рассылки всем. То есть получение, распределение
и рассылка должны быть в рамках одной логической транзакции. Методы
достижения
• Все каналы транзакционные и операция в рамках одной
физической транзакции
• Помнить по каждому сообщению кому послали, а кому нет.
Постоянное хранилище
• В случае сбоя рассылка возобновляется с самого начала.
Получатели должны быть устойчивы к повторному получению
сообщения. Если это не так, то можно перед ними вставить
«фильтр повторяющихся сообщений»
  Вариант шаблона – динамический список получателей, управляемый по
специальному каналу потенциальными потребителями.
• Тесно смыкается с «динамическим маршрутизатором»
• Используется для эмуляции в средах, где не поддерживаются
топики или с получателями, которые не могут осуществлять
подписку на топики
 Общие принципы. Список рассылки тем более эффективен, чем
• Чем менее среда поддерживает на низком уровне
широковещательную рассылку. Крайний случай - интернет
• чем дальше находится получатель, тем эффективнее список
рассылки по сравнению с «публикация-подписка»
• чем меньше селективность потребления среди потенциальных
потребителей
 чтобы собрать реакцию получателей обратно в одно сообщение
применяется шаблон «агрегатор». Вместе они составляют шаблон
«рассылка - сборка»
o Разветвитель (Splitter) – раздельная обработка частей одного сообщения

 Можно конечно отправлять сообщение целиком всем и пусть каждый

обработает свою часть, но
• Образуется слишком тесная связь приложений
• Возможность множественной обработки одной части
• Лишний трафик. Изрядная часть сообщения вообще может никем
не обрабатываться, а приходить просто в силу фиксированного
формата сообщения источника. Очень актуально для В2В
взаимодействия
 Некоторые части исходного сообщения войдут во все формируемые,
например «заголовок заказа» и ИД исходного сообщения
• Позволяет обеспечить самодостаточность каждого сообщения
• Позволяет сопоставить ответы с исходным сообщением и
сформировать единый ответ
 Разновидности разветвителей
• Итеративный – когда данные в виде дерева: берем все ветки узла и
для каждого формируем отдельное сообщение, общее их число
заранее не известно, тип одинаков. Все выше трактуем, например,
как общий заголовок
o Позволяет абстрагироваться от конкретной схемы данных в
сообщении
o Часто дальше идет «маршрутизатор на основе содержания»,
распределяющий выделенные части по подсистемам, где
они могут быть обработаны
o Альтернативные названия – итератор (iterator) или
сиквенатор (sequencer)
• Статический – разделение сообщения на фиксированное
количество частей различных типов.
o Часто каждое публикуется в отдельном канале,
соответствующем его типу
 o Аналог широковещательного канала с фильтрами
содержимого подписчиков
 Удобно для облегчения последующей работы агрегатора
• формируемые сообщения нумеровать в рамках одной
последовательности
• каждому прописывать CorrelationId
o Агрегатор (Aggregator) – сборка разных, но связанных между собой
сообщений обратно в одно целое.

 Сбор результатов множественной обработки одного сообщения или

частей одного, предварительно разделенного сообщения
 Основная проблема – условие полноты
• сколько сообщений собирать в одно, особенно актуально, когда
использовалась широковещательная рассылка
o ожидать всех, общее число сообщения содержится в первом
или в каждом
 используется когда неполный результат обработки не
имеет смысла, например при сборе заказа
 Самый медленный и уязвимый вариант. Можно
поправить перезапросом, но это связывает агрегатор
с обработчиками
o первый - лучший, для аукционов, бирж и других ситуаций с
критичным временем ответа
• как долго ожидать прихода последнего ответа. Особенно, когда
клиенты могут часть времени быть не активными.
o Сильно влияние бизнес логики – баланс между полнотой и
временем отклика системы
o Фиксированное время ожидания. Дальше либо использовать
что есть, либо диагносцировать попытку, либо
перезапрашивать ответ.
o Время ожидания с досрочным завершением
 по первому же сообщению, удовлетворяющему
некоторому критерию
 по достижению агрегируемого параметра заданного
порога
o По наступлению внешнего управляющего события
 Специальный фильтр с сохранением состояния.
• Иногда не обязательно хранить все ответы, можно «лучший» или
вообще усредненное состояние полученных ответов
• Можно собрать воедино все данные для дальнейшей обработки
другим компонентов
 Корреляция вопросов и ответов чаще всего производится на основе
CorrelationId и ИД исходного сообщения
 порядок прихода ответов может отличаться от исходного порядка
запросов, ответы на различные запросы могут перемешиваться между
собой – одновременно формируется несколько агрегатов.
 • Получение очередного сообщения сопровождается созданием
нового агрегата или обновлением уже имеющегося.
• Добавление сообщение к каждому сопровождается проверкой
условия его полноты
 Варианты создания нового агрегата
• Самосоздающиеся на основании CorrelationId пришедшего
сообщения. Недостаток – обработка «опоздавшего» сообщения уже
«закрытого» агрегата. Решения
o хранение перечня «закрытых» агрегатов, но его надо как-то
периодически чистить, при этом не слишком рано
o каждое сообщение несет в себе длину агрегата
• Создавать агрегат на основании события разделения сообщения -
инициализированный
o Минус - более сложно и сильно связывает два компонента.
Требует дополнительного управляющего канала, по
которому, например, придет исходное сообщение.
o Плюс – позволяет хранить в агрегате данные, которые не
содержатся ни в одном из разделенных запросов / ответов.
 Часто сочетается с шаблонами «разветвитель» и «список рассылки» в
результате возникают сложные шаблоны «составное сообщение» и
«рассылка-сборка»
 Вариант использования «выявление пропавших сообщений». Помогает,
когда клиент не является транзакционным. В этом случае невозможно
обеспечить гарантированную доставку, так как сообщение может быть
утрачено после получения, но до обработки. Решение
• Сообщение раздваивается, одно сообщение по ненадежному
каналу
• Второе в обход через через канал гарантированной доставки
• Второе сообщение и результат обработки первого встречаются в
агрегаторе, который может выявить пропавшее сообщение на
основе условия «время ожидания с досрочным завершением»
o Публикация сообщения об ошибке
o Повторная высылка обработчику утраченного сообщения
o Преобразователь порядка (Resequencer) – восстановление исходного
порядка ответов в соответствии с порядком запросов

 Основная причина нарушения порядка – асинхронная выборка сообщений

для обработки + разное время на обработку каждого сообщения + разная
скорость каналов передачи
 Можно отправлять сообщения по одному по мере обработки
предыдущего, но
• Значительно замедляется работа системы. Не допускается
параллельная обработка сообщений. Большое время простоя
компонент
• Приходится завязаться на получение сообщений от
обрабатывающих компонент – сложно и возрастает связанность
системы. Не всегда можно контролировать исходный поток
 Фильтр с сохранением состояния
 •получает сообщения, хранит их во внутренних буферах до полного
получения каждой последовательности, публикует содержимое
буфера в правильной последовательности
• может хранить только часть последовательности, относительно
которой выявлен неправильный порядок - последний полученный
и уже отправленный 9, очередной 11, значит ждем 10, по его
получению отправляем в правильном порядке
 В каждом сообщении – ИД последовательности (часто он же ИД
корреляции) и порядковый номер сообщения в последовательности.
 Проблема генерация порядковых номеров.
• Как ид можно использовать GUID или MAC+время обработки. С
порядковым номером сложнее – они должны образовывать
непрерывную последовательность
• Может быть узким местом процесса разветвления, лучше
встраивать непосредственно в разветвитель
 Проблема переполнения буфера
• Источники
o длинный по своей природе поток сообщений в транзакции,
o сбой компонента, обрабатывающего только сообщения
определенного типа – тормозит все последовательности
• решения
o при работе с очередью иногда БПС позволяет выбирать
«задние» не трогая очередные. Стандартным способом –
только просматривать, выбирать нельзя
o контролировать работу поставщика сообщений используя
уведомления о старте / остановке работы. Можно
уведомлять поставщика об объеме свободного буфера,
чтобы тот мог сгенерировать определенный объем
сообщений
o генерация заменителя отсутствующего сообщения – если
потребитель и природа данных подобное позволяют,
например, при передаче голоса по IP сетям
o Обработчик составного сообщения (Composed Message Processor) –
корректная обработка сообщения из нескольких элементов, каждый из
которых обрабатывается отдельно

 Составные части: разветвитель, маршрутизатор, обрабатывающие

компоненты, агрегатор
 Альтернативы
• можно использовать результат обработки по каждой ветке
отдельно, но это не всегда удобно получателю. Особенно когда
части как-то зависят друг от друга.
• Можно последовательно передавать сообщение целиком с этапа на
этап – перерасход трафика, простой компонентов, возможность
блокировки
 Оптимизация работы агрегатора – поступление от сплитера уведомления
о создании последовательности с указанием числа сообщений в ней
  С внешней точки зрения обработчик есть просто фильтр с одним входным
и одним выходным каналом
o Рассылка – сборка (Scatter-Gather) – рассылка одного сообщения
нескольким получателям и обработка набора ответов

 Составные части – широковещательная рассылка + агрегатор ответов, от

обрабатывающих компонент. Два основных варианта
• Рапределение с помощью списка получателей. Лучше
контролируется перечень получателей, но о них надо знать
• Аукцион – публикация в топике. Отсутствует контроль над
перечнем получателем. Не известно заранее сколько будет ответов
– затрудняется работа агрегатора
 Отличие от «обработчика составного сообщения»
• рассылается исходное сообщение, а не формируется много новых
из данных исходного
• не столь критична синхронизация обработки на отдельном этапом
и сборки результата, меньше вероятность блокировки
• алгоритм работы агрегатора как правило сложнее
 В сообщение можно вставлять адрес возврата результата, тогда
агрегаторов можно сделать больше и гибкость увеличивается
o Карта маршрутизации (Routing Slip) - обработка сообщения на нескольких
этапах в ситуации, когда на этапе проектирования их последовательность
не известна и варьируется от типа сообщения

 Критерии эффективности решения: только через нужные компоненты,

число каналов / компонентов / маршрутизаторов не должно быть
чрезмерным, маршрут должен быть гибким, простота добавления новых
типов сообщений, компоненты не должны простаиваться
 Варианты решения на основе «каналы и фильтры»
• Сообщение через все возможные обработчики, каждый сам решает
обрабатывать или нет
o Просто, фактически реактивная фильтрация
o Смешение бизнес логики с логикой маршрутизации –
затруднено повторное использование компонент
o Невозможно, когда разные сообщения проходят одни и те
же этапы в разном порядке
 • Перед каждым обработчиком маршрутизатор, решающий
«направить или пропустить»
o требуется, чтобы необходимость могла быть вычислена
локально перед этапом
o перерасход компонент всех типов. Все сообщения идут
через всю цепочку – велика нагрузка по трафику
o логика маршрутизации распределена, появление нового
типа сообщения вызывает необходимости
переконфигурирования всех маршрутизаторов
• Входной маршрутизатор, дальше для каждого возможного
варианта обработки своя простая последовательность
обработчиков
o Наиболее эффективная и простая стратегия
o Легко добавлять логику для нового типа сообщений
o Требуется заранее вычислить и задать все возможные
варианты обработки – перерасход компонент, ненужное
дублирование
o Очень не удобно поддерживать при большом количестве
типов сообщений
• После каждого обработчика маршрутизатор, решающий куда гнать
дальше
o Отличие от маршрутизатора «перед» - может пробрасывать
сразу через много этапов обработки, в том числе и назад
o Не решается проблема централизации контроля логики.
Логика обработки по-прежнему распределена
• Единый «супермаршрутизатор», который отправляет на очередной
этап, получает ответ, вычисляет следующий, отправляет ему и так
далее – центральный брокер запросов
o Плюсы
 компоненты задействованы только необходимые
 конфигурация достаточно гибкая. В том числе можно
менять схему обработки по мере прохождения этапов
o Минусы
 сложность реализации
 необходимость хранить для каждого сообщения
контекст обработки или пересылать, раздувая трафик
 минимум двухкратное превышение трафика за счет
пробега «туда-обратно»
 излишняя централизация = снижение надежности
 Карта маршрутизации – компромисс с последним вариантом
• в начало обработки вставляется компонент, вычисляющий
последовательность этапов обработки и вставляющий ее в само
сообщение – потенциальная точка сбоя
• Каждый компонент после осуществления обработки смотрит в
перечень этапов и высылает сообщение в адрес следующего
обработчика
• Начальный компонент может действовать на основе ИД операции,
этапы выполнения которой зашиты в конфигурации системы. Одна
логическая функция динамически раскрывается в несколько этапов
обработки
 Плюсы
 • Сочетание централизованного управления и оптимальность жестко
заданной последовательности операций.
• Логика маршрутизации проста и универсальна для всех компонент
обработчиков, поэтому ее можно задублировать между
компонентами или же вынести в адаптеры компонент
• Можно усложнить логику, внедряя в таблицу условия выполнения
этапов, ветвление и т.д. Тогда получится «диспетчер процессов» с
описанием процесса и его состоянием внутри сообщения
• Полностью распределенная система – устойчива к сбоям не считая
первого этапа
 Минусы
• Сообщение слегка раздувается
• Если сообщение теряется, то теряются не только его данные, но и
состояние процесса обработки. Не известно на каком именно этапе
оно потерялось - нет центральной точки отчетности
• Невозможность варьировать последовательность этапов по мере
обработки и на основании результатов каждого этапа
• Последовательность операций должна быть линейной, циклы и
ветвления не поддерживаются
• Сложно отлаживать – информация о ходе процесса обработки
находится внутри сообщения
 Использование с унаследованными приложениями, которых невозможно
дополнить логикой маршрутизации на основе карты
• Вход – входная очередь + адаптер канала
• Выход – адаптер канала + выходная очередь + универсальный
маршрутизатор
 Область применения
• Цепочка бинарных этапов проверки. На каждом из этапов
обработка либо прерывается, либо продолжается на следующем
этапе из листа
• Каждый этап обработки есть преобразование без сохранения
состояния. Тогда список может быть дополнен информацией, к
какой части сообщения надо применить преобразование и с какими
параметрами
• На каждом этапе производится сбор данных, но не принимаются
решения. Например – расширение содержимого сообщения, в
котором в исходном варианте представлены только ссылки. Правда
не вполне понятна зачем подобному сценарию такая гибкость
 Может использоваться как альтернатива маршрутизатору на основе
содержимого
• В начале обработке в сообщение вставляется список всех
потенциальных получателей.
o В данном случае он выполняет роль цепочки обязанностей.
o Вставляющий компонент по-прежнему должен знать всех
участников системы, но не должен помнить какой из них
какие сообщения может обрабатывать
• Перед каждым получателем маршрутизатор с логикой
o Обработать и закончить процесс
o Передать следующему по списку обработчику
• Плюсы
o нет риска многократной обработки одного сообщения
 o легко выявлять сообщения не прошедшие ни одного этапа
обработки
• Минусы
o низкая скорость обработки и увеличение объема трафика.
o Число опубликованных сообщений в среднем равно
половине числу компонент.
 Для маршрутизатора на основе содержимого – одно
сообщение
 Можно скомпенсировать, направляя сначала тому
обработчику, который с наибольшей вероятностью
сможет его обработать
o Диспетчер процессов (Process Manager) – многоэтапная обработка
сообщения, когда на момент проектирования системы перечень и
последовательность их не известны и варьируются в зависимости от типа
сообщения и результата выполнения очередного этапа

 Основная идея – после каждой операции сообщение возвращается в

центральную точку контроля для вычисления следующего этапа
обработки. Топология звезды
 Хранение контекста (экземпляра) процесса
• В сообщении – оно раздувается и становится зависимым от
процессора
• В процессоре – необходимо использование постоянного
хранилища. Для связи экземпляра с сообщением применяется
идентификатор корреляции
• Иногда необходимо хранить информацию, которая понадобится
«через этап» или привязана к конкретному прохождению одного
этапа. В этом случае процессор работает как квитанция, позволяя
этапам не зависеть друг от друга
 Плюсы
• Есть центральная точка и администрирования и отчетности
• максимальная гибкость, таким образом можно реализовать
практически любой процесс обработки
• легко накладывать аспекты безопасности и логирования, удобно
отлаживать и профилировать
• хорошо описываются диаграммами деятельности из UML,
поддерживаются средствами проектирования и документирования
при помощи визуальных средств
• легко отслеживать сколько процессов в каких состояниях в
текущий момент активно. Для других архитектур реализуется
крайне сложно
• поддерживается языками и стандартами описания бизнес
процессов – XLANG, WSFL, BPEL и т.д.
• несколько диспетчеров процессов можно запускать в параллель так
как экземпляры в общем случае не зависят друг от друга
 Минусы
 •сложность реализации
•необходимость хранить как описания процессов, так и состояния
отдельных экземпляров процессов
• архитектура «звезда», центральная точка критична к сбоям, узкое
место потока информации
o Брокер сообщений (Message Broker) – разделение пунктов назначения и
отправителей между собой + централизованный контроль над обменом
сообщений

 Базовые варианты маршрутизации

• Маршрутизация за основе каналов, частая ситуация – много
компонент в системе и каждый связан каналами с каждым.
Возникает в результате постепенного расширения когда-то простой
системы
o Затратно по ресурсам
o Слабо управляемо и расширяемо
• Маршрутизация на основе топиков – не обеспечивает необходимой
вариативности
• Маршрутизация на основе маршрутизаторов – много М не лучше,
чем много каналов
 Брокер сообщений – централизованный компонент, который получает и
принимает сообщения от своих клиентов, архитектура «завезда».
• Не шаблон проектирования, а архитектурный шаблон – оппозиция
шаблону «каналы и фильтры»
• Составной компонент, внутри набор маршрутизаторов сообщений
 Основной недостаток – центральное узкое место. Отсюда ненадежность и
перерасход трафика. Методы коррекции
• Если брокер не хранит состояние – можно развернуть много
экземпляров
• Разделение всей системы на домены, отвечающие наиболее
интенсивному информационному обмену.
o Каждому домену отдельный брокер и центральный для
междоменного обмена.
o Обратная сторона – спагетти брокеров. Лечение – иерархия
брокеров по принципу организации подсетей
 Использование брокера не снимает проблем преобразования форматов
данных. Часто при этом брокер становится местом локализации
канонической модели данных + преобразователей из/в для каждого
компонентного формата.

Трансформация сообщений
o Оболочка конверта (Envelope Wrapper) – интеграция существующих
приложений в ситуации, когда среда обмена предъявляет специальные
требования к формату сообщения
  Как правило связано
• с наличием специальных полей для выполнения маршрутизации,
выполнения шифрования / подписи трафика, идентификации /
аутентификации
• поддержки обмена сообщениями между разными БПС – мост
сообщений
• поддержка специального протокола – FTP, HTTP, SSH
 упаковщик, как правило, добавляет к сообщению некоторую
информацию, в этом плане он напоминает «расширитель содержимого».
НО в отличии от сведения нужны не адресату, а инфраструктуре
 специальная операция – продвижение (promotion), вынесение какой-то
информации из тела сообщения в заголовок, чтобы сообщение могло быть
специальным образом обработано. Изоляция среды от специфики
структуры сообщения
 зачастую приходится использовать многоуровневую вложенность,
соответствующую уровням приложения – прикладной, транспортный,
сетевой и т.д.
o Расширитель содержимого (Content Enricher) – предоставление получателю
дополнительных сведений, которыми не обладает (или не публикует)
отправитель

 Частный случай транслятора сообщения, использующего внешнее

хранилище данных
 Альтернативы
• Модифицировать приложение отправитель – не всегда можно,
противоречит принципу изоляции и независимости систем друг от
друга
• Получатель сам запрашивает необходимую информацию от
отправителя – избыточная зависимость получателя от отправителя
• Модифицировать набор компонентов, вынести управление
данными в отдельный компонент и транзитом гнать сообщение
через него – слишком чувствительно к изменению бизнес
процессов, надо менять уже имеющиеся приложения
 Источники данных для расширителя:
• вычисление недостающих по уже имеющимся
• извлечение из среды (метка времени) или другой системы (база
даных)
 •раскрытие ссылок (часто применяется, чтобы снизить объем
сообщения на каких-то этапах, когда данные реально нужны
далеко не всем обработчикам). Реально это «сообщение с
квитанцией»
• Так как расширитель по своей природе тесно связан с источником
данных, то взаимодействие с ним как правило синхронное
o Фильтр содержимого (Content Filter) – сокращение данных и/ или
упрощение структуры сообщения в случае, когда получателя интересует
лишь малая часть данных

Причины
• экономия трафика и вычислительных ресурсов
• безопасность
• упрощение процедуры обработки
• редукция универсальных В2В форматов типа RosettaNet, ebXML,
ACORD
• снижение зависимости от внешнего формата
• упрощение отладки
• использование поставляемых вендорами адаптеров канала,
которые поставляют данные в соответствии с внутренней
структурой приложения
 Набор из нескольких фильтров, подписанных на исходный топик, может
служить разветвителем, делаящим исходное сообщение на фрагменты,
обрабатываемые отдельно друг от друга
 Альтернатива – вешать свои адаптеры канала на вьюхи в базе данных,
отфильтровывающие необходимые данные уже в готовом оптимальном
виде
o Квитанция (Claim Check) – сокращение объема данных в пересылаемом
сообщении

 Основные компоненты: фильтр содержимого, сохраняющий удаляемое в

базе данных, поле с ИД данных в сообщении, расширитель содержимого
на основании базы и ИД данных
 Особенно удобное, когда XML сообщение с внедренными CDATA,
особенно бинарниками
 Плюсы (кроме объема трафика)
• Снижает зависимость промежуточных систем от информации для
них не предназначенной
• Увеличивает безопасность
 •Увеличивается производительность, так как однократное чтение /
запись в базу более эффективно.
o при передаче между компонентами важные и большие
данные все равно ложатся в базу
o затраты на сериализацию / десериализацию, шифрование /
дешифрование и т.д.
 Особенно удобно когда сообщение пройдя через цепочку обработки
возвращается отправителю. А основная часть данных нужна ТОЛЬКО
отправителю
 Выбор ключа
• В теле сообщения уже есть бизнес ключ, например ИД клиента.
Плюс – унификация обработки таких ключей
• Ключ в базе = ИД сообщения: это делает ненужным поле в
сообщении, но
o может встретиться вложенное «сокращение – расширение»
или сообщение пройдет через один редуктор несколько раз
и в базе будет конфликт.
o Сообщения могут упаковываться друг в друга, меняя ИД.
Или порождать друг друга
• УИД
 Удаление данных из базы
• Компонент, расширяющий сообщение. Строго, но нельзя
использовать одни и те же данные несколько раз
• По мере устаревания
• Не удалять вовсе, например для систем бухучета
 Специальный вариант использования – безопасность
• можно скрывать конфиденциальные данные на время обработки,
заменяя ее на абстрактные УИД-ы. Например – ИД кред. Карточек,
имена, адреса и т.д.
• контроль за доступом к закрытой информации локализуется в
расширителе
• политика сокрытия информации локализуется в редукторе
 диспетчер процессов тоже использует квитанцию для хранения состояния
процесса обработки
o Нормализатор (Normalizer) – унификация сообщений различных по
формату перед обработкой

 Сочетание маршрутизатора в зависимости от формата и набора

трансляторов
 плюсы
• Защита системы от изменяющихся неконтролируемых форматов
данных. Особенно необходимо в В2В когда много партнеров и их
перечень часто меняется
• Возможность применять одни и те же алгоритмы к данным разных
партнеров. Иногда потом придется денормализовывать
  Распознавание формата исходного сообщения
• Поле заголовка
• Корневой элемент XML тела или набор XPath
• Наименование поступившего файла-сообщения или его
расположение в иерархии папок
o Каноническая модель данных (Canonical Data Model) – минимизация числа
зависимостей между данными при интеграции множества независимых
приложений

 плюсы
• минимизация числа преобразований из квадрата числа приложений
в удвоенное их количество
• Если формат сообщений какого-то приложения меняется или
добавляется новое приложение , то надо изменять или добавлять
только два транслятора
• Позволяет легко видоизменять части, имеющие дело только с
общей моделью
• Позволяет обсуждать проблему терминах проблемы, а не
конкретной модели данных конкретного приложения
 Минусы
• Два преобразование вместо одного – «двойная трансляция».
Недопустимо для систем, требующих быстрого отклика. Частично
лечится если запустить несколько трансляторов в параллель
• Нельзя воспользоваться выигрышами, типа близости форматов
сообщений двух каких-то приложений друг к другу
 Способы
• Изменение формата сообщения приложения – очень редко
• Внедрение в приложение преобразователь формата обмена
сообщениями – когда приложение разработано нами
• Внешний транслятор сообщений – типовой случай
o От приложения до транслятора – закрытое сообщение
o Дальше – открытое сообщение

Конечные точки обмена сообщениями

o Общие замечания
 Приложение должно быть максимально изолировано от специфики
работы с подсистемой обмена сообщениями. Также изолирующая
прослойка как правило ответственна за:
• Преобразование данных
• Выбор транзакционной модели – по умолчанию транзакция работы
с подсистемой сообщений изолированная, но можно ее включить в
рамки транзакции приложения
 Шаблоны потребителей сообщений
• Синхронный или асинхронный потребитель – опрашивающий или
событийно управляемый
 •выборка одни потребителем или конкурентная выборка
несколькими, возможно контролируемая диспетчером
• принятие всех сообщений или фильтрация
• постоянная подписка или online прослушивание
• возможность повторного получения сообщений
• синхронная или асинхронная обработка сообщений
 сложности
• Основная проблема – скорость потребления сообщений (throttling).
Если слишком высокая – перегрузка сервера. Если более низкая –
накопление сообщений в канале
• Обработка внешних транзакций
o Транзакционный клиент + опрашивающий потребитель –
ограниченная по производительности модель
o Событийно ориентированный как правило не способен
транзакционно обрабатывать сообщения
o Диспетчер – можно, но сложно реализовывать
o Конкурирующие потребители чреваты проблемами
• Плюсы MDB – хорошо продуманный сервис: диспетчер сообщений
с пулом потребителей, трудно своими руками
o событийные и поддерживающие распределенные
транзакции
o конкурентная выборка
o Шлюз обмена сообщениями (Messaging Gateway) – инкапсуляция доступа к
системе обмена сообщениями, скрывающая ее от остальных частей
приложения

 Проблемы
• вызовы внутри приложения в большинстве своем синхронные, а
API большинства систем обмена сообщениями – асинхронные.
Шаблон «запрос - ответ»
• достижения слабого связывания связано с использованием XML и
требует перекодировки
• выполнение одной функции зачастую требует посылки / получения
нескольких сообщений. Шаблон «рассылка - сборка»
 лучший способ - выделение специфики в DAO подобный код, или шлюз с
API,специфичным для предметной области
 Плюсы
• Легко заменить одну систему обмена на другую. Изоляция от
специфики API
• В процессе тестирования и отладки шлюз легко заменить на
симулятор
• Возможность получения кодом приложения осмысленных
исключений
• Код шлюза легко сгенерировать на основании метаданных.
Особенно для веб служб на основе WSDL
 Типы шлюзов
 •Блокирующий – изолирует приложение от асинхронного обмена,
проще код, но страдает производительность
• Событийно ориентированный
o как правило приложение вместе с параметрами
регистрирует в методе callback вызов, специфичный для
предметной области. В состав исходных параметров и
параметров callback вызова входит маркер асинхронного
вызова, идентифицирующий операцию
o можно просто вернуть метку запроса, а потом периодически
опрашивать шлюз на предмет готовности результатов –
полусинхронная обработка
 объединение шлюзов в цепочки – последовательная абстракция:
предметная, до уровня очереди сообщений, до уровня платформы обмена
сообщениями
o Преобразователь обмена сообщениями (Messaging Mapper) – как
организовать перемещение данных между сообщениями и объектами
предметной области

 Традиционные альтернативы
• транслятор сообщения, особенно часто используется при
интеграции сторонних приложений для преобразования к
канонической модели данных.
o Как правило поддерживается вендорами.
o Не способен решать проблемы сборки оптимального графа
объектов и удаление ненужных данных
• автоматическая сериализация объектов - плохо управляемо,
сообщение непроницаемо, проблемы с отладкой и тестированием,
инфраструктура не сможет проверить формат сообщения,
межплатформенная несовместимость
• XML сериализация – сложная задача, особенно если язык не
поддерживает сериализацию, требовательная к ресурсам
 Более эффективно – сразу программно формировать необходимое
сообщение
• без промежуточного сообщения и потерь на его обработку
• можно управлять степенью гранулированностью данных в
зависимости от бизнес специфики. Ликвидация перезапросов и
множественных вызовов
• корректная обработка типов данных и ссылок между объектами
 одно сообщение может включать данные нескольких объектов
приложения разных классов в зависимости от потребности операции
интеграции
 хороший выбор – кодогенерация на основе метаданных, сочетание
гибкости и эффективности. Можно иметь 2 ветки – на основе отражения и
на основе кодогенерации. Разрабатывать на одной, эксплуатировать на
второй
  Хорошо сочетается с шаблоном «объектов-значений», фактически одно и
то же со всеми преимуществами
 Можно применять совместно с транслятором сообщений – на его долю
выпадает адаптация структуры уже сформированного сообщения под
каноническую модель данных. Проигрыш в производительности, но
выигрыш в адаптивности
o Транзакционный клиент (Transactional Client) – управление со стороны
клиента транзакциями, в рамках которых он работает с сообщениями

 Транзакции
• локальные – отправили или нет, потребили или нет
• распределенные, например, двухэтапные – скопировать сообщение,
чтобы в любой момент оно было либо / либо
 Конечные точки – по своей природе транзакционны, то есть состояние
канала атомарно, согласованно и изолировано. Устойчивость –
опциональна для гарантированной доставки
 Более сложные сценарии, в рамках одной транзакции требуется
• Отправить / получить сообщение
o начать Т, получить и обработать сообщение 1, отослать
сообщение 2, подтвердить Т
o транзакция может быть как простой, так и распределенной,
например в рамках моста обмена сообщениями
o нельзя в рамках той же транзакции дождаться ответа на
свой запрос
• Работа с группой сообщений
o Начать, отослать или считать все сообщения, подтвердить
o Простая транзакция
o Гарантирует сохранение порядка сообщений получателем
• Сообщение + база данных, часто используется адаптером канала
для БД
o Начать, обновить БД, подтвердить. Или начать, обновить
БД, отправить
o Распределенная транзакция
• Сообщение + рабочий поток, то есть действие + отсылка
сообщения или прием сообщения + действие
o Начать, выполнить, отправить подтвердить. Или начать,
получить, закрыть, подтвердить
o Распределенная транзакция
 Для событийно управляемых клиентов как правило сначала
осуществляется подтверждение получения, а затем обработка. Поэтому
они в большинстве случаев не транзакционны, то есть откат сообщения
сделать нельзя
 Сами системы обмена могут участвовать в распределенных транзакциях,
но это не стандарт
 Хорошо сочетается с – «запрос-ответ», «цепочка сообщений», «адаптер
канала», «фильтры сообщений»
  Плохо сочетается с – «получатель с событием», «событийно управляемый
потребитель», «диспетчер сообщений», «конкурирующие потребители»
o Опрашивающий потребитель (Polling Consumer) – потребление
приложением сообщения только тогда, когда оно готово это сделать, с
удобной для себя интенсивностью, а не по мере поступления в канал,
синхронное получение

 Обычно поток блокирует свое выполнения на время ожидания очередного

сообщения. Используется, когда сообщения поступают часто.
Интенсивность выборки регулируется числом конкурентно выбирающих
из канала потоков
 Можно сделать один выбирающий поток на несколько каналов, тогда
блокировать поток в ожидании сообщения не надо. Используется, когда
сообщения поступают редко, а каналов много.
 Основной недостаток – неэффективность, слишком часто опрашивает или
слишком долго стоит. Решение – событийно управляемый потребитель
 Хорошо подходит в качестве транзакционного клиента так как сам решает
когда подтвердить получение сообщения
o Событийно управляемый потребитель (Event-Driven Consumer) –
оптимальное получение сообщений по мере их обработки, асинхронный
получатель активируемый системой обмена сообщениями

 Компенсация основного недостатка опрашивающего потребителя

 Основная идея – канал сам уведомляет потребитель о поступлении
сообщения, потребитель активирует обратный вызов получателя.
Обработка по одному сообщении за раз
 Получатель НЕ способен регулировать интенсивность получения
сообщений, но расходует ресурсы более эффективно
 Крайне нежелательно сочетать с транзакционным клиентом
o Конкурирующие потребители (Competing Consumers) – параллельная
обработка нескольких сообщений одним и тем же клиентом
  Проблема – при слишком медленном получении сообщения начинают
скапливаться в канале. Основные причины
• Отправителей много, получатель один
• Ликвидация простоя сети или получателя
• Трудоемкость обработки сообщений
 Решение
• несколько получателей на канале «точка-точка» каждый в
собственном потоке, пока один обрабатывают – другие ждут
новых сообщений
• координация на стороне канала. В оптимальном случае (диспетчер
сообщений) канал выдаст сообщение только одному, в худшем –
даст завершить транзакцию обработки только одному. Стандартом
не определено, что реализовано – надо мерить
 для топика не применимо – сообщения будут дублироваться
 не решает проблему в том случае, когда узкое место – сам канал
 могут быть как опрашивающими (потоки на стороне клиента), так и
событийно управляемыми (потоки на стороне системы сообщений)
o Диспетчер сообщений (Message Dispatcher) – согласованное распределение и
обработка сообщений между потребителями одного и того же канала

 Отличие
• от конкурирующих потребителей и других шаблонов
o потребители могут быть не эквивалентными
o может применяться стратегия распределения сообщений в
зависимости от состояния потребителей
o преимущество конкурирующих потребителей – они могут
располагаться в разных процесса, а диспетчер через RPC –
 это неправильно, так как время распределения сообщения
должно быть минимальным
• от селективных потребителей
o распределение может выполняться на основе глубокого
анализа сообщения, например тела
o условия могут быть слишком сложны или просто не
поддерживаться инфраструктурой
o проблема сообщений не подпадающих ни под одно условие
• в любом случае решает проблему повторной обработки одного
сообщения без необходимость осуществления координации
потребителей между собой
 реальные потребители – исполнители могут
• создаваться диспетчером на ходу – скорость ограничена временем
создания потока
• выбираться из пула ожидающих. – скорость ограничена числом
выделенных потоков и средним временем обработки сообщения
 может быть как событийно управляемым, так и опрашивающим. Только в
последнем случае поддерживает транзакционную обработку. Но требуется
больше ресурсов и сложнее в разработке
o Избирательный потребитель (Selective Consumer) – потребитель определяет
какие сообщения он хочет получать

 Альтернатива
• Получает все, остальное передает другим обработчиком. Зависимо
и ненадежно
• Получают все все и обрабатывают только свое - трудно избежать
двойной обработки
• По каналу на тип получателя – слишком затратно по ресурсам,
трудно перестраивать систему, критерии – свойство получателя, а
не канала
• Маршрутизатор на основе содержимого – менее гибко, критерий
отделяется от получателя
 Проблема пересечения условий выборки – основная для формирования и
обслуживания группы потребителей
• несколько избирательных на одной очереди – конкурирующие
потребители, проблема недоставленных сообщений
• несколько избирательных на одном топике – проблема
недоставленных и дважды доставленных сообщений
 недопустимо, когда часть сообщений секретны – невозможно
разграничить доступ, в этом случае лучше использовать каналы типы
данных или диспетчер сообщений
 чтобы избавиться от сообщений, которые никому из потребителей не
нужны – использовать фильтр перед.
o Постоянный подписчик (Durable Subscriber) – сохранение сообщения для
временно отключенного от системы потребителя
  Решение проблемы переполнения очереди – установка срока действия
сообщений или ограничение размера очереди для подписчика
o Идемпотентный получатель (Idempotent Receiver) – обработка повторно
доставляемых сообщений
 При использовании изначально ненадежных протоколов единственный
способ гарантированной доставки – повторная отправка до достижения
подтверждения. Побочный эффект – двойная доставка
 Двойники могут появиться и при сбое распределенной транзакции
 Способы достижения
• Явное выявление и удаление дубликатов – приходится вводить
УИД-ы сообщений и хранить перечень уже полученных.
o Проблема его длинны и хранить ли его постоянно. Сходство
с шаблоном «преобразователь порядка»
o Можно использовать в качестве УИД-а бизнес ключ. НО
возможны проблемы потом, если, например, клиент захочет
не только регистрировать, но и обновлять заказы
• Определение семантики с учетом идемпотентности
o Не «изменить баланс на 10 единиц», а «установить баланс
равным 10 единицам».
o Не решает проблем, когда дубли разделены другими
сообщениями
o Активатор службы (Service Activator) – сервис, вызываемые как через
систему обмена сообщениями, так и локально, как асинхронно, так и
синхронно. Адаптация службы к системе обмена сообщениями

 Варианты использования
• когда служба должна вызываться и синхронно и асинхронно.
Тогда организуем доступ и через сессионные бины и через MDB
• Различные каналы доступа к службе
 Сам сервис всегда вызывается синхронно. Разделение приложения на
синхронные и асинхронные слои

 Активатор может работать в обоих направлениях, шаблон «запрос-ответ»
  Активатор может использоваться для кэширования информации и
снижения нагрузки на службу. Может активировать службу и т.д. См
шаблон «прокси»
 Может быть как событийным, так и опрашивающим

Управление системой
o Общие замечания
 Основные проблемы
• Обработка многих тысяч сообщений в день
• Динамически возникающие узкие места
• Системы эволюционируют
• Гибкость и слабое связывание компонент выходит боком при
администрировании и тестировании
• Асинхронная природа и неопределенные временные параметры
процессов
 Уровни абстракции
• Управление системой – сколько и каких сообщений было
доставлено, как долго длится обработка сообщений и т.д.
• Мониторинг бизнес активности – на основе полезной информации
в сообщениях. Например, стоимость обрабатываемых заказов и
потери из-за простоя
 Категории шаблонов
• Мониторинг и управление – «шина управления» компонентами,
временное включение системных механизмов через «обходной
путь»
• Наблюдение и анализ трафика сообщений – журнал доставки
сообщений, централизованное хранилище сообщений, перехват
сообщений с помощью отвода
• Тестирование и отладка – тестовое сообщение и вентиль канала
o Шина управления (Control Bus) – средство эффективного управления и
наблюдения за территориально распределенной системой обмена
сообщениями

 Традиционные механизмы конфигурирования на основе файлов

оказываются неприменимы в случае территориально распределенной
системы: задержки, разные протоколы доступа к СВТ, безопасность
 Вариант с посылкой конфигурационных, управляющих и
информационных сообщений по обычным каналам:
• Для управляющих нужны более строгие политики безопасности
• В случае переполнения очереди управляющие могут просто не
дойти вовремя или не вместиться в очередь
• У служебных сообщений как правило другой приоритет
относительно данных. Например, логирование
 В результате каждый компонент имеет минимум три канала связи
• Бизнес каналы - входной и выходной
 •Управляющий канал, часто заведенный на единую шину
управления, с другой стороны подключенной к консоли
управления
 Типы сообщений, передающиеся по шине
• Конфигурационные – адреса каналов, селекторы, таймауты,
таблицы маршрутизации
• Пульсы – информирование консоли о том, что компонент жив.
Если не просто флаг активности, а еще и какие-то данные, то это
статистическое сообщение
• Тестовое сообщение – вбрасываем в поток бизнес и смотрим
соответствует ли его путь и результаты обработки заданному
• Исключения – передаются от компонент на консоль и в единую
подсистему логирования
 На данную тему стандартов нет, каждый вендор выкручивается по-своему
o Обходной путь (Detour) – направление сообщения на прохождение
дополнительного этапа обработки с целью проверки правильности, отладки
или тестирования

 В принципе выполнение тройки данных операций полезно перед каждым

компонентом, но ест ресурсы.
• Остро требуется на этапах отладки системы, поиска проблем,
настройке производительности.
• В языке программировании аналоги – операция «assert», функции
логирования
 Переключение между двумя путями обработки выполняется
• из центра если маршрутизатор имеет внешний канал управления.
Можно включать / отключать операции по признаку группам
обработчиков
• на основании флага в самом сообщении. Можно включать /
отключать операции по бизнес процессам
o Отвод (Wire Tap) или тройник - средство просмотра сообщений, часто
данных документов, передаваемых по каналу «точка-точка»

 Альтернативы
• Чтобы отправитель и получатель сами публиковали бы дубли –
требует вмешательства в уже имеющиеся компоненты
• Замена на «публикация-подписка» - меняет семантику операции,
может возникнут впоследствии множественная обработка одного
сообщения
 •Просмотр сообщений в очереди без потребления – не видно
сообщений, которые получатель уже потребил
• Промежуточный получатель – если требуются данные из
нескольких источников, то изменится динамика распространения
сообщений и поведение канала
 Оптимальный способ – промежуточный компонент, который удваивает
сообщение, публикуя его одновременно для получателя и для отдельного
анализирующего компонента.
 Его удобно сделать опционально работающим через шину управления.
 Основные недостатки
• некоторая задержка, особенно если сообщение все равно
декодирует БПС даже если его реального использования не
происходит. Зависит от вендора
• новое сообщение получает новые ИД и метку времени исходного.
Если ИД используется дальше в качестве идентификатора
корреляции, то система может отказать, так как нарушится связь
между сообщениями
 часто в цепочку вставляют несколько отводов, чтобы
• сравнить информацию из сообщений до и после некоторой
цепочки обработки. Тогда компонент-анализатор выполняет роль
хранителя сообщений
• вычислить время обработки сообщений
o Журнал доставки сообщений (Message History) – эффективный анализ и
отладка пути следования сообщений в слабо связанной системе

 Слабая связность – основная характеристическая черта систем,

основанных на обмене сообщениями. Сильно затрудняет отладку, так как
• отправитель ничего не знает о получателе и наоборот.
• Процесс обработки сообщения в целом не существует, существует
только его текущее состояние
• Сложно оценить влияние на систему без знания истории обработки
 Шина интересуется отдельными компонентами, но не отслеживает
сообщения.
 Альтернатива – каждый компонент публикует ИД обработанного
сообщения в центральном хранилище сообщений. Но
• Требуется модификация всех компонентов и развитая
инфраструктура
• Если для обработки сообщения требуется смотреть его историю –
база станет общим местом
• ИД-ы сообщений могут меняться, даже когда фактически
сообщение одно и то же. Например, на любом маршрутизаторе
• Сообщения могут разделяться, сливаться и размножаться
 Решение – журнал обработки, встроенный внутрь самого сообщения.
Каждая запись по уникальному ИД компонента соотносится с операцией.
Как правило выносится в заголовок, так как относится к системе, а не к
бизнес данным
  Для агрегированных сообщений - журнал в виде дерева, журнал
сообщения выбранного в качестве «основного», например для аукциона –
победившего сообщения
 Альтернатива – диспетчер процессов, сам по себе необходимо
осуществляет логирование всех операций по обработке сообщения,
сложное решение
 Полезно в ситуации, когда несколько источников совместно читают и
пишут одни и те же данные посредством топика для предотвращения
зацикливания сообщений об изменении данных.
o Хранилище сообщений (Message Store) – использование содержимого
сообщений в отчетах без нарушения слабой связности системы

 Асинхронный характер гарантирует доставку, но не определяет ее время.

Знать его иногда критично важно, причем по различным выборкам
сообщений
 Вариант – анализ журналов обработки сообщений, но
• Их надо как-то агрегировать
• Выделять для каждого типа сообщений отдельно перед последним
потреблением, когда сообщение исчезает
 В данном случае предлагается, чтобы каждый компонент топравлял два
сообщения – получателю и в служебный канал для хранилища.
• Можно данную ответственность возложить на отвод
• В хранилище можно слать не все сообщение, а только часть
содержательную для анализа. Тела как правило мало интересны и
не всегда в принципе анализируемы
• Так как бросаем и забываем, то на производительности системы в
целом не сказывается
 Основная проблема – структура хранилища
• Для каждого типа сообщения своя структура хранения с таблицами
и индексами. Быстро, но сложно. Надо разбирать, а потом сшивать
для выборки и анализа
• Универсальное хранилище на основе XML – медленно
 Обязательно надо предусматривать процедуры очистки устаревших
данных, возможно переноса в архивную базу
o Интеллектуальный заместитель (Smart Proxy) - как отслеживать
сообщения, проходящие через службу, если ответы публикуются в каналы,
заданные в сообщении обратным адресом
  Традиционно анализ работы службы производится путем пары отводов,
но тут не понятно куда ставить второй отвод. Особенно критично для
унаследованных или высоко универсальных служб
 Решение
• все запросы поступают в ИЗ (он же первый отвод)
• там извлечь и сохранить обратный адрес
• вместо него вставить адрес интеллектуального заместителя (он же
второй отвод)
• ИЗ, получив сообщение, отправит его по первоначальному
сохраненному обратному адресу
 ИЗ удобно использовать и тогда, когда внешний сервис не поддерживает
работу с обратными адресами. В этом случае он возьмет на себя
разбрасывание ответов по обратным адресам
 Как сохранять обратные адреса
• Внутри сообщения – добавляет новое поле, сервис обработчик
должен скопировать его в сообщение ответ. Оптимально, но не
всегда возможно
• Внутри ИЗ – требуется, чтобы обработчик поддержал работу с
идентификатором корреляции. Это практически всегда возможно.
 Лучше, чтобы ИЗ сам создавал свои идентификаторы корреляции,
• Не все отправители сообщений их используют.
• Они уникальны только в рамках отдельных источников сообщений
и могут повторяться
• Служба может использовать ИД поступившего сообщении в
качестве ИД корреляции. А он никак к исходному сообщению не
относится
• чтобы они работали локально в рамках процесса
• входной идентификатор корреляции, если он есть, сохраняется и
восстанавливается вместе с обратным адресом. Если его нет –
используется ИД входного сообщения
o Тестовое сообщение (Test Message) – автоматическое выявление
компонентов со сбойным поведением. Механизм активного мониторинга

 Составляющие шаблона
• Генератор тестовых данных. Данные используются для создания
тестовых сообщений и для проверки результатов обработки
тестовых сообщений
• Вбрасыватель тестовых сообщений. Они должны как-то отличаться
от нормальных по флагу в заголовке или по уникальным значениям
каких-то бизнес полей
• Отделитель сообщений – результатов обработки тестовых,
используется маршрутизатор на основе содержимого. Если
компонент поддерживает обратный адрес, то можно обойтись без
 отделителя. В тестовом сообщении обратный адрес просто надо
сделать адресом анализатора
• Верификатор тестовых данных. На основе исходных тестовых
данных и результата их обработки выявляет возможные сбои в
работе компонента.
 Минусы
• Повышенная нагрузка
• Если компонент использует платные ресурсы – стоимость
обработки тестовых сообщений
• Результат обработки тестовых сообщений потенциально может
менять данные в базе. Компонент не всегда способен отличить
тестовую платежку от нормальной
o Вентиль канала (Channel Purger) – удаление ненужных сообщений из
канала, чтобы они не мешали отладке или эксплуатации системы

 Когда включаем / выключаем инициаторы и ответчики в канале могут

сохраняться старые сообщения, которые будут сбивать логику обмена
запросами и ответами.
 Обратная сторона надежности доставки и слабой асинхронной связи
отправителя и получателя
 проблемы
• Нельзя запустит реальные данные, пока полностью не потреблены
тестовые.
• Если сообщение неправильно сформировано и получатель падает
его не обработав
 Решения
• Идентификаторы корреляции – не защищает от данных,
уничтожающих компонент
• Использование временных каналов – только для отправителя,
получателю не поможет
 Вентиль канала
• В простейшем случае извлекает из канала все сообщения и
уничтожает их
• Иногда сохраняет для анализа или повторной отправки