Содержание к диссертации
Введение
ГЛАВА 1. Анализ и обоснование интеграционных решений для распределённых информационных систем обмена сообщениями 17
1.1. Задачи интеграции 17
1.1.1. Необходимость интеграции 17
1.1.2. Типы интеграционных задач 18
1.1.3. Проблемы интеграции 22
1.1.4. Обеспечение слабого связывания 24
1.2. Способы интеграции 26
1.2.1. Критерии интеграции приложений 26
1.2.2. Передача файлов 29
1.2.3. Общая база данных 30
1.2.4. Удалённый вызов процедур 32
1.2.5. Обмен сообщениями 34
1.3. Системы обмена сообщениями 36
1.3.1. Построение систем обмена сообщениями 36
1.3.2. Архитектура Публикация/Подписка 48
1.4. Анализ и выбор механизма уведомления 51
1.4.1. Выбор на основе канала 51
1.4.2. Выбор на основе темы 52
1.4.3. Выбор на основе содержимого 53
1.5. Маршрутизация на основе содержимого 54
1.5.1. Простая маршрутизация 55
1.5.2. Маршрутизация на основе покрытия 56
1.5.3. Использование Рекламных объявлений
1.6. Задачи исследования 57
1.7. Выводы з
ГЛАВА 2. Разработка формальной спецификации систем публикация/подписка 60
2.1. Интерфейс системы Публикация/Подписка 60
2.2. Спецификация на основе следа 62
2.3. Поведение систем Публикация/Подписка 65
2.4. Модель системы Публикация/Подписка 68
2.5. Конфигурация маршрутизации
2.5.1. Переадресация уведомлений: таблицы маршрутизации 69
2.5.2. Статическая система Публикация/Подписка:
допустимая маршрутная конфигурация 72
2.5.3. Динамическая система Публикация/Подписка:
слабо допустимая маршрутная конфигурация 82
2.6. Самостабилизирующаяся система Публикация/Подписка 85
2.6.1. Самостабилизирующиеся системы 86
2.6.2. Самостабилизирующаяся система Публикация/Подписка
2.7. Система Публикация/Подписка с рекламными объявлениями 88
2.8. Выводы 89
ГЛАВА 3. Маршрутизация сообщений на основе содержимого 93
3.1. Обобщённая структура алгоритмов маршрутизации 93
3.2. Алгоритмы маршрутизации
3.2.1. Алгоритм с "наводнением" 106
3.2.2. Простая маршрутизация на основе фильтров 110
3.2.3. Маршрутизация на основе идентичности фильтров 115
3.2.4. Маршрутизация на основе покрытия фильтров 121
3.2.5. Маршрутизация на основе объединения фильтров
3.3. Маршрутизация с рекламными объявлениями 133
3.4. Обеспечение самостабилизации 136
3.4.1. Предположения об отказах 136
3.4.2. Аренда записей маршрутной таблицы 137
3.4.3. Условия выбора и прекращения срока аренды 137
3.4.4. Самостабилизация алгоритмов маршрутизации 139
3.4.5. Время стабилизации 140
3.5. Выводы 141
ГЛАВА 4. Реализация систем обмена сообщениями на основе архитектуры публикация/подписка 144
4.1. Инфраструктура сервиса уведомлений Rebeca 145
4.1.1. Общая архитектура 145
4.1.2. Использование алгоритмов маршрутизации 145
4.1.3. Механизм воспроизведения уведомлений 145
4.1.4. Концепция фабрик сервисов 146
4.1.5. Основные классы 147
4.2. Использование инфраструктуры сервиса уведомлений Rebeca 154
4.2.1. Реализация события 154
4.2.2. Реализация потребителя 155
4.2.3. Реализация поставщика 156
4.2.4. Реализация журнала 157
4.2.5. Реализация фабрики 158
4.2.6. Запуск маршрутизатора 160
4.2.7. Процедура использования 161
4.3. Примеры приложений 161
4.3.1. Самообновляющиеся веб-страницы 162
4.3.2. Торговля акциями 164
4.3.3. Виртуальная медицинская организация 168
4.4. Выводы 176
ГЛАВА 5. Анализ реализуемых алгоритмов маршрутизации 178
5.1. Общие настройки 179
5.1.1. Брокерская топология 180
5.1.2. Характеристики потребителей 181
5.1.3. Характеристики производителей 182
5.2. Размеры таблиц маршрутизации 183
5.2.1. Простая маршрутизация 184
5.2.2. Простая маршрутизация с объявлениями 184
5.2.3. Маршрутизация на основе идентичности фильтров 185
5.2.4. Маршрутизация на основе идентичности с объявлениями 187 5.2.5. Маршрутизация на основе покрытия фильтров 188
5.2.6. Маршрутизация на основе покрытия фильтров с объявлениями 189
5.2.7. Маршрутизация на основе объединения/слияния фильтров 189
5.2.8. Маршрутизация на основе слияния фильтров с объявлениями 190
5.3. Издержки на фильтрацию и пересылку данных 190
5.3.1. Простая маршрутизация 190
5.3.2. Простая маршрутизация с объявлениями 192
5.3.3. Маршрутизация на основе идентичности фильтров 192
5.3.4. Маршрутизация на основе идентичности с объявлениями 192
5.3.5. Маршрутизация на основе покрытия фильтров 193
5.3.6. Маршрутизация на основе покрытия фильтров с объявлениями 193
5.3.7. Маршрутизация на основе объединения/слияния фильтров 195
5.3.8. Маршрутизация на основе слияния фильтров с объявлениями 195
5.4. Дополнительные эксперименты 195
5.4.1. Эффекты локальности интересов потребителей 195
5.4.2. Оценка несовершенного слияния 201
5.5. Выводы 204
Заключение 208
Список условных обозначений 211
Список литературы 213
- Обеспечение слабого связывания
- Переадресация уведомлений: таблицы маршрутизации
- Маршрутизация на основе идентичности фильтров
- Использование инфраструктуры сервиса уведомлений Rebeca
Обеспечение слабого связывания
Типичная информационная система предприятия насчитывает сотни, если не тысячи, приложений (коммерческих, собственной разработки, унаследованных и т. д.), выполняющихся под управлением различных операционных систем. Это обусловлено рядом причин.
Во-первых, разработка бизнес-приложений - сложная задача. Создание единственного приложения, охватывающего все бизнес-функции предприятия, практически невозможно. Наибольшего успеха в создании тяжеловесных бизнес-приложений достигли разработчики ERP-систем. Однако даже такие гиганты индустрии как R/3 SAP AC, Baan, Oracle, Peoplesoft и др., вынуждены сконцентрировать свои усилия лишь на части бизнес-задач типичной компании.
Во-вторых, распределение бизнес-функций между несколькими приложениями предоставляет компаниям возможность выбора "лучшего" пакета программ для бухгалтерского учета, "лучшего" приложения для управления взаимоотношениями с клиентами, "лучшей" системы обработки заказов и др. Учитывая многообразие индивидуальных бизнес-требований предприятий, создание универсального бизнес-приложения не входит в интересы разработчиков программного обеспечения (ПО).
Современные бизнес-приложения создаются для решения определенных задач. Тем не менее, нескончаемый поток требований к расширению функциональности со временем приводит к появлению в программном пакете дополнительных функций. Для поддержания общих бизнес-процессов, а также совместного использования данных несколькими приложениями последние необходимо интегрировать [1 - 3]. Основной целью интеграции является обеспечение эффективного, надежного и безопасного обмена данными между интегрируемыми приложениями.
Под интеграцией будем понимать объединение компьютерных систем, компаний или людей. Несмотря на то, что термину интеграция дано очень широкое определение, остановимся на шести наиболее распространенных типах интеграции [2, 4, 5]:
Приведенный выше список не претендует на исчерпывающую классификацию задач интеграции, тем не менее, он дает наглядное представление о проектах, над которыми работают архитекторы интеграционных решений. Некоторые интеграционные задачи объединяют в себе сразу несколько типов интеграции. К примеру, создание распределенного бизнес-процесса зачастую требует проведения начальной репликации данных между объединяемыми приложениями.
Основная функция информационных порталов (рисунок 1.1) заключается в обеспечении представления информации из нескольких источников. В самых простых информационных порталах экран разделяется на несколько зон, каждая из которых соответствует той или иной системе. Более сложные порталы поддерживают ограниченное взаимодействие между зонами, например выбор пользователем элемента списка в зоне А приводит к отображению подробной информации об этом элементе в зоне Б. Самые сложные информационные порталы за счет высокого уровня функциональности практически стирают грань между порталом и интегрированным приложением.
Многие бизнес-системы нуждаются в доступе к одним и тем же данным. Например, такая информация, как адрес проживания клиента, может использоваться системой обслуживания заказчиков (при изменении адреса клиента), системой бухгалтерского учета (при подсчете налога с продаж), системой доставки товаров (при создании этикетки с адресом доставки), а также биллинговой системой (при формировании счета). Некоторые из этих систем могут иметь собственное хранилище данных. При изменении адреса клиента каждая система должна получить копию обновленной информации. Этого можно добиться с помощью такого типа интеграции, как репликация данных (рисунок 1.2).
Существует множество различных способов реализации репликации данных. Функция репликации может быть встроена в СУБД, нужные сведения можно экспортировать в файл для последующего импорта другой системе или пересылать в виде сообщений всем задействованным бизнес-системам с помощью соответствующего связующего ПО. Во многих бизнес-приложениях реализована избыточная функциональность. Так, например, сразу нескольким системам может понадобиться проверить номер социального страхования, правильность почтового индекса в адресе проживания или же наличие определенного товара на складе. Каждую из этих функций можно вынести за пределы приложений и реализовать в виде функции совместного использования, доступной всем системам в виде определенной службы (рисунок 1.3).
Совместно используемая бизнес-функция и репликация данных могут преследовать схожие цели. Выбор между двумя различными типами интеграции основывается на многочисленных критериях, таких, как степень контроля над интегрируемыми системами (в отличие от помещения информации в базу данных, вызов совместно используемой функции предполагает более глубокое вмешательство в систему) или частота изменения данных (доступ к адресу проживания клиента осуществляется часто, а вот вероятность изменения последнего невысока).
Совместно используемые бизнес-функции часто называют службами. Служба - это строго определенная и универсально доступная функция, реагирующая на запросы своих потребителей. Управление службами является одной из наиболее важных задач компании. Во-первых, интегрируемым приложениям необходимо предоставить доступ к централизованному списку всех доступных служб (каталогу служб). Во-вторых, описание интерфейса каждой службы должно способствовать согласованию контракта взаимодействия приложения с этой службой. Обнаружение службы и согласование контракта взаимодействия с ней -две важнейшие составляющие SOA-архитектуры (рисунок 1.4). п.
SOA-архитектура {Service-oriented arhitecture) стирает грань между интеграцией приложений и созданием распределенного приложения [6]. К примеру, при создании нового приложения разработчики могут полагаться на службы, предоставляемые другими приложениями. В этом случае обращение к службе может быть расценено как интеграция приложений. Однако во многих SOA-архитектурах вызов внешней службы практически ничем не отличается от вызова локального метода (за исключением производительности). Таким образом, разработку нового приложения в рамках существующей SOA-архитектуры можно сравнить с созданием распределенного приложения.
Одним из ключевых признаков того, что приложения необходимо интегрировать, является участие нескольких различных систем компании в выполнении единственной бизнес-транзакции (например, размещении заказа клиентом). В большинстве случаев вся функциональность, необходимая для выполнения бизнес-транзакции, сконцентрирована в существующих приложениях. Для координации выполнения бизнес-функций, принадлежащих различным системам компании, необходимо создать компонент управления распределенным бизнес-процессом (рисунок 1.5).
Переадресация уведомлений: таблицы маршрутизации
В статических системах публикации/подписки набор участвующих брокеров, связи между ними и подписки локальных клиентов всё время их работы постоянны. В таких системах маршрутная конфигурация должна гарантировать, что уведомление, опубликованное для произвольного клиента, будет доставлено любому клиенту с соответствующей подпиской. Допустимая маршрутная конфигурация, представленная ниже, удовлетворяет этим условиям.
Неформально брокер должен различать две группы уведомлений: 1) множество уведомлений vB {{Y}), которые направляются локальным клиентам; 2) множество уведомлений vB {{В}), которые направляются соседним брокерам. Рассмотрим vB ({Г}). Система является "правильной", если удовлетворяет условию, что брокер доставляет точно те уведомления каждому из локальных клиентов, которые ему интересны. Это означает, что vB ({У}) всегда должно быть эквивалентно Fes N(F), где Sy множество активных подписок Y (т. е. все фильтры, на которые 7 подписался и пока не аннулировал подписку). Если vB ({Y}) будет содержать больше уведомлений, то будет нарушено требование безопасности системы. Если vB ({У}) будет содержать меньше уведомлений, эти уведомления никогда не будут доставлены, и в этом случае нарушается требование живучести системы.
Рассмотрим vB ({В }), которое, по меньшей мере, должно содержать все уведомления, интересные локальным клиентам и соседним брокерам. Но, так как топология связей брокеров ациклична, то этот набор должен дополнительно содержать и такие уведомления, в которых заинтересованы клиенты, связанные с соседними брокерами. Если это не так, то некоторые из этих клиентов не получат всех интересующих их уведомлений. В отличие от Vg ({У}) множество Vg {{В }) может содержать больше уведомлений, чем это необходимо, потому что финальная фильтрация достигается через фильтрацию vB {{Y}). Конечно, этот избыток должен быть как можно меньше, чтобы не была превышена пропускная способность сети. Эти требования необходимы и достаточны для того, чтобы статическая маршрутизация уведомлений поддерживала корректное функционирование системы.
Определим 1в как множество всех уведомлений, которые интересны любому из локальных клиентов брокера В: 1в= х,ьв Р хтП- (2.19) Заметим, что 1в меняется каждый раз, когда клиент подписывается на определённое сообщение или аннулирует его. Рассмотрим некоего брокера Bt и одного из его соседних брокеров Bj. Если между Bt и Bj нет связи, то G разделяется на два несвязанных подграфа: один содержит Ви а другой Bj. Допустим, что &в. в = (Ув- в Ев- в ) есть подграф, содержащий все вершины, связанные с Д-. Множество всех уведомлений, которые интересны хотя бы одному потребителю любого брокера из VB% в , обозначим как
Диаграмма локальной допустимости маршрутной конфигурации Допустимая маршрутная конфигурация называется совершенной, если в удалённой допустимости подмножество отношений заменяется равенством. Совершенная маршрутная конфигурация гарантирует, что ни одно из уведомлений не будет доставлено напрасно. Это, с одной стороны, минимизирует использование пропускной способности сети, а с другой - может привести к уменьшению таблиц маршрутизации.
Докажем, что если допустимая маршрутная конфигурация используется в сочетании с алгоритмом, приведенным на рисунке 2.3, то система публикации/подписки будет удовлетворять требованиям безопасности и живучести, сформулированным в определении 2.1. Представим доказательство в виде последовательности шагов разных уровней, например, 1 2 есть второй шаг доказательства на уровне 1. Каждый шаг содержит утверждение, которое может быть доказано на нижних уровнях с помощью дополнительных шагов. Представление доказательства в таком структурированном виде дает возможность читать только его верхние уровни, опускаясь на подуровни, если это необходимо [76].
Доказать, что удовлетворяется требование безопасности системы, можно с помощью проверки трёх его составляющих (определение 2.1), что и приведено в леммах 1-4. Требование живучести системы проверено в лемме 5. Вместе эти результаты сведены в теорему о корректности системы.
Докажем утверждение, что всегда, если клиент будет уведомлен о «, то он больше никогда не будет уведомлен о п снова. Действительно, каждое уведомление п может быть опубликовано только один раз, так как уведомления уникальны. Из алгоритма, представленного на рисунке 2.3 (пересылка уведомлений), ацикличности графа G и в связи с предположением о надёжности канала следует, что п может быть доставлено клиенту только один раз.
Докажем, что если клиент уведомлен об п, то п было опубликовано ранее одним из других клиентов. Это следует из алгоритма и предположения о надёжности канала. Доказательство проводится в обратном порядке: от доставки и к её публикации в соответствии с топологией сети.
Маршрутизация на основе идентичности фильтров
Введенное определение является достаточно сложным, и служит базисом для последующих утверждений, поэтому рассмотрим его толкование и значение более подробно. Определение состоит из трех требуемых выполнения свойств. Свойство 1 требует прекращения действий администратора по истечении конечного времени, свойство 2 определяет условия допустимости для текущей конфигурации маршрутизации, а свойство 3 определяет требования, которые должны выполняться для множества возвращаемых троек.
Рассмотрим, что, по сути, означают эти свойства. Свойство 1 обеспечивает завершение процедуры администрирования по истечении конечного промежутка времени. Свойство 2 задает условия допустимости для текущей конфигурации маршрутизации. Свойство 2а гарантирует, что именно необходимые уведомления будут доставлены заинтересованному в них клиенту. Свойство 2Ь обеспечивает соблюдение условий взаимодействия брокеров, установленных допустимой исход 99 ной конфигурацией маршрутизации. Свойство 2с означает, что сообщение т, полученное от локального клиента или соседа, может повлиять только на конфигурацию маршрутизации, касающуюся его пунктов назначения.
Свойство 1 вместе с алгоритмом маршрутизации, а также фактом ацикличности топологии сети, гарантирует прекращение каждого процесса обновления по истечении конечного промежутка времени. Без данного свойства условие живучести может быть нарушено (см. определение 2.1).
Без свойства 2а могут быть нарушены либо условия безопасности (локальному клиенту могут быть отправлены не интересующие его уведомление) или живучести (локальному клиенту могут быть отправлены не все интересующие его уведомления).
Условие, обеспеченное свойством 2Ь, гарантирует, что, по меньшей мере, все уведомления, которые брокер В направляет брокеру S, S направит, в свою очередь, своим соседям или доставит своим локальным клиентам. Это свойство позволяет брокеру локально принимать решение о маршрутизации.
Свойство 2с ограничивает изменения, которые могут возникнуть в результате сообщения типа admin, только той частью конфигурации маршрутизации, которая касается S. Это упрощает дальнейшие рассуждения.
Свойство 3 обеспечивает, что процесс обновления доходит до всех соседей, чьи маршрутные таблицы должны обновиться.
Теперь докажем, что, если процедура администрирования допустима для данной допустимой начальной конфигурации маршрутизации, то система публикации/подписки удовлетворяет требованиям безопасности и живучести определения 2.1. Во-первых, докажем, что каждый процесс обновления завершается, если процедура администрирования допустима (лемма 1). Далее покажем, что конфигурация маршрутизации всегда слабо допустима (см. определение 2.3), если про 100 цедура администрирования допустима для данной допустимой начальной конфигурации маршрутизации (леммы 2, 3 и 4). Вместе с теоремой 2.3 о слабой допустимости маршрутной конфигурации в динамических системах публикации/подписки это приводит, в итоге, к теореме, которая доказывает исходное утверждение.
Лемма 3.1. Если процедура администрирования допустима, то все процессы обновления завершаются.
Алгоритм обобщённой структуры маршрутизации гарантирует, что брокер В не передаст сообщение администратора обратно брокеру, от которого он его получил. Это утверждение, наряду с тем, что каждый процесс обновления имеет уникальный идентификатор, и что процедура администрирования завершается по истечении конечного времени (первое свойство определения 3.2), а также ацикличности сети, доказывает завершение каждого процесса обновления.
Докажем важное для маршрута брокеров условие (включение) доставки сообщения клиенту-подписчику.
Если процедура администрирования допустима для данной допустимой исходной конфигурации маршрутизации, то для всех клиентов Y выполняется следующее свойство:
Утверждается, что, если процедура administer является допустимой для данной допустимой начальной конфигурации маршрутизации, и процесс обновления все еще активной подписки F завершен, а отмена подписки на F никогда не происходила, то каждый брокер ВкФ BY на уникальном маршруте, ведущем к подписавшемуся клиенту, направляет, по крайней мере, все соответствующие F уведомления единственному соседу - следующему брокеру на маршруте. Доказательство этого свойства представлено в виде индукции на маршруте от Bk к By.
Требуется доказать, что УВкФ BY . Vg ({Bm}) N(F), где BY - брокер, управляющий 7, а Вт - следующий брокер на маршруте от Bk к Y. 1. Пусть ВРІ , Bpi_i, ... , Bpi, BY - это маршрут от некоторого брокера Врг ф BY К BY , где BY - брокер, управляющий Y. Маршрут является точно определенным и уникальным вследствие ациклической и связной топологии графа G. 2. Рассмотрим терминальный случай: vB ({BY}) N(F). Сначала мы докажем справедливость свойства в момент прекращения процесса обновления F, а затем, что данное свойство справедливо всегда. 1. Y подписался на F и отправил сообщение т типа sub{F) к BY- Доказательством служит представленный алгоритм. 2. Процедура administer вызывается BY при получении сообщения т и возвращает необходимое значение. Доказательством служат шаг 2 1, алгоритм, свойство 1 определения 2 и надежность каналов. 3. По завершению процедуры administer всегда справедливо, что предположение 3. 4. Далее BY либо отправляет сообщение т типа admin с id{mx) = idQn), по направлению к Вр\, либо не отправляет. Доказательством служат шаг 2 2 и алгоритм. 5. Рассмотрим случай, когда BY отправил сообщение тх типа admin с id(m ) = id(m) к ВР\. m запускает вызов процедуры администрирования administer в Врі, которая также возвращает своё значение по истечении конечного промежутка времени. Доказательством служат свойство 1 допустимого администрирования, надежность каналов и алгоритм. 2. Из свойства 2Ь допустимого администрирования следует, что справедливо доказываемое утверждение 5 ({BY}) N(F). 6. Рассмотрим случай, когда By не отправил сообщение тх типа admin с id(m ) = id(m) по направлению к ВР\. Тогда утверждение 5 ({BY}) = N(F) вытекает из свойства 3. 7. Поскольку верно v» ({BY}) N(F) в момент прекращения процесса обновления F, то оно продолжает действовать всегда. Доказательством служат шаги 2 5, 2 6 и свойства 2Ь и 2с. 8. Доказываемое утверждение следует из 2 5, 2 6 и 2 7. 1 3. Рассмотрим шаг индукции. Предположим, что для Bpt.\ и Bpt.2 справедливо У в р. ({Bpi-2}) N(F). Докажем, что для BPi и ВРі.\ справедливо
Использование инфраструктуры сервиса уведомлений Rebeca
Local EventBroker - это EventBroker, который не подключен ни к одному EventRouter (рисунок 4.1), этот класс полезен только при реализации локальной системы публикации/подписки. LocalEventBroker имеет RoutingEngine, который реализует используемый алгоритм маршрутизации.
RemoteEventBroker - это LocalEventBroker (рисунок 4.1), который дополнительно устанавливает подключение к EventRouter, по этому подключению идет обмен событиями Event в соответствии с используемым алгоритмом маршрутизации. Само подключение реализуется классом EventTransport. TCPEventBroker TCPEventBroker - это RemoteEventBroker (рисунок 4.1), который использует EventSocketTransport для подключения к EventRouter по указанному IP-адресу и номеру порта. DefaultEventBroker DefaultEventBroker - это EventBroker, который инкапсулирует экземпляр EventBroker. Обычно он инициализируется с помощью DefaultEventBroker.init (args) в методе main. 152 EventTransport EventTransport реализует двунаправленное подключение, с помощью которого выполняется обмен экземплярами Event (рисунок 4.1): public abstract class EventTransport { public Event readEvent (); public void writeEvent (Event e); } EventSocketTransport EventSocketTransport - это EventTransport (рисунок 4.1), который использует Socket для обмена событиями Event как сериализированными объектами JAVA посредством ObjectlnputStream и ObjectOutputStream.
EventQueueTransport - это EventTransport (рисунок 4.1), который использует локальную очередь для обмена событиями, поэтому этот класс можно использовать только для подключения к партнерам, расположенным на той же виртуальной машине JAVA.
RoutingTable реализует функции таблицы маршрутизации, необходимые для алгоритмов маршрутизации на основе фильтрации (рисунок 4.4). В основном RoutingTable состоит из набора экземпляров RoutingEntry, которые можно добавлять, удалять или запрашивать, например, набор пунктов назначения, соответствующих заданному уведомлению, можно определить с помощью метода Set getDestinations (Event є).
EventProcessor Интерфейс EventProcessor является, по существу, механизмом обратного вызова, реализованным для определения конечной точки доставки уведомлений, если поступает соответствующее уведомление, вызывается метод process(Event е) с уведомлением в качестве параметра (рисунок 4.5): public interface EventProcessor { public void process (Event e);
EventQueue - это EventProcessor (рисунок 4.5), который помещает в очередь входящие уведомления. Первое уведомление в очереди можно извлечь с помощью блокирующего метода Event consume() или неблокирующего метода Event tryConsume(). SubscriptionEvent Если потребитель оформляет новую подписку, автоматически создается событие SubscriptionEvent (рисунок 4.2), которое содержит соответствующий класс Subscription. Эта операция выполняется с помощью соответствующего LocalEventBroker.
UnsubscriptionEvent Если потребитель отменяет активную подписку, автоматически создается событие UnsubscriptionEvent (рисунок 4.2), которое содержит соответствующий класс Subscription. Эта операция выполняется с помощью соответствующего LocalEventBroker.
SubscriptionSubscription SubscriptionSubscription - это подписка Subscription, соответствующая событиям SubscriptionEvent, подписка Subscription которых пересекается с заданным фильтром Filter. Кроме того, можно проверить, пересекается ли необязательное описание ReplayDescription подписки с заданным ReplayDescription. SubscriptionSubscription используется журналами и фабриками.
Событие ReplayEvent (рисунок 4.2) публикуется журналами при получении SubscriptionEvent. Оно создается на основе заданного события Event и полученного события SubscriptionEvent. Инфраструктура обеспечивает доставку ReplayEvent только потребителям, имеющим подписку, встроенную в SubscriptionEvent.
Использование инфраструктуры сервиса уведомлений Rebeca Описывается, как можно использовать инфраструктуру уведомлений REBECA ДЛЯ создания простого распределенного приложения, основанного на механизме публикации/подписки.
Предположим, у нас есть потенциальные потребители событий ExampleEvent, публикуемых неким поставщиком. Поставщик должен быть активным только в том случае, если подписка оформлена, хотя бы одним потребителем. Кроме того, новым потребителям должны доставляться десять последних опубликованных ExampleEvent. Это приложение состоит из фабрики, управляющей поставщиком, журналом и, по меньшей мере, одним потребителем. Ниже приводятся классы, необходимые для реализации этого примера, и описывается сам пример. Все упомянутые классы являются частью распространяемой инфраструктуры REBECA.
Класс ExampleProducer расширяет класс DefaultEventProducer. Сначала выдается объявление о намерении опубликовать события ExampleEvent, а затем публикуются ExampleEvent каждые 3 секунды. Эта операция выполняется в отдельном потоке во избежание блокировки вызывающего потока. Запустить ExampleProducer можно, вызвав Java Events.example.ExampleProducer.
