Войти
В архитектуре программного обеспечения публикация – подписка - это обмен сообщениями шаблон, где отправители сообщений, называемые издателями, не программируют сообщения для отправки непосредственно определенным получателям, называемым подписчиками, а вместо этого классифицируют опубликованные сообщения по классам, не зная, какие подписчики, если таковые имеются, может быть. Точно так же подписчики выражают интерес к одному или нескольким классам и получают только те сообщения, которые представляют интерес, не зная, какие издатели существуют, если таковые имеются.
Публикация – подписка является аналогом парадигмы очереди сообщений и обычно является частью более крупной системы промежуточного программного обеспечения, ориентированной на сообщения. Большинство систем обмена сообщениями поддерживают модели pub / sub и очереди сообщений в своем API, например Служба сообщений Java (JMS).
Этот шаблон обеспечивает большую масштабируемость сети и более динамическую топологию сети, что приводит к снижению гибкости для изменения издателя и структуры публикуемых данных.
В модели публикации-подписки подписчики обычно получают только подмножество всех опубликованных сообщений. Процесс выбора сообщений для приема и обработки называется фильтрацией. Есть две распространенные формы фильтрации: тематическая и контентная.
В тематической системе сообщения публикуются в «темах» или именованных логических каналах. Подписчики в тематической системе будут получать все сообщения, опубликованные по темам, на которые они подписаны. Издатель отвечает за определение тем, на которые подписчики могут подписаться.
В системе на основе содержимого сообщения доставляются подписчику только в том случае, если атрибуты или содержимое этих сообщений соответствуют ограничениям, определенным подписчиком. Подписчик несет ответственность за классификацию сообщений.
Некоторые системы поддерживают гибрид из двух; издатели отправляют сообщения в тему, в то время как подписчики регистрируют подписки на основе содержимого на одну или несколько тем.
Во многих системах публикации / подписки издатели отправляют сообщения промежуточному брокеру сообщений или шине событий, а подписчики регистрируют подписки у этого брокера, позволяя брокеру выполнять фильтрация. Посредник обычно выполняет функцию сохранения и пересылки для маршрутизации сообщений от издателей к подписчикам. Кроме того, брокер может назначать приоритет сообщениям в очереди перед маршрутизацией.
Подписчики могут зарегистрироваться для получения определенных сообщений во время сборки, инициализации или выполнения. В системах с графическим пользовательским интерфейсом подписчики могут быть запрограммированы для обработки пользовательских команд (например, щелчка кнопки), что соответствует регистрации времени сборки. Некоторые платформы и программные продукты используют файлы конфигурации XML для регистрации подписчиков. Эти файлы конфигурации считываются во время инициализации. Самая изощренная альтернатива - это когда подписчиков можно добавлять или удалять во время выполнения. Этот последний подход используется, например, в триггерах базы данных, списках рассылки и RSS.
Промежуточное ПО службы распространения данных (DDS). не использует посредника. Вместо этого каждый издатель и подписчик в системе публикации / подписки обмениваются метаданными друг о друге через многоадресную IP-рассылку. Издатель и подписчики кэшируют эту информацию локально и маршрутизируют сообщения на основе обнаружения друг друга в общей осведомленности. Фактически, без брокерской архитектуры требуется система публикации / подписки для построения оверлейной сети, которая обеспечивает эффективную децентрализованную маршрутизацию от издателей к подписчикам. Джон Кляйнберг показал, что эффективная децентрализованная маршрутизация требует навигационных топологий Small-World. Такие топологии Small-World обычно реализуются децентрализованными или федеративными системами публикации / подписки. Системы публикации / подписки с учетом местоположения создают топологии Small-World, которые направляют подписки через короткие расстояния и недорогие ссылки, тем самым сокращая время доставки подписки.
Одной из первых публично описанных систем публикации / подсистемы была «новостная» подсистема Isis Toolkit, описанная в 1987 г. Association for Computing Machinery (ACM) Конференция симпозиума по принципам операционных систем (SOSP '87), в статье «Использование виртуальной синхронизации в распределенных системах. 123–138».
Издатели слабо связаны с подписчиками, и им даже не нужно знать об их существовании. Поскольку в центре внимания находится тема, издателям и подписчикам разрешается игнорировать топологию системы. Каждый из них может продолжать работать в обычном режиме независимо от другого. В традиционной парадигме «клиент-сервер» традиционной тесной связи клиент не может отправлять сообщения на сервер, пока серверный процесс не запущен, а также сервер не может получать сообщения, если клиент не запущен. Многие системы публикации / подписки не только разделяют местоположение издателей и подписчиков, но и временно разделяют их. Обычная стратегия, используемая аналитиками промежуточного программного обеспечения с такими системами публикации / подписки, состоит в том, чтобы отключить издателя, чтобы позволить подписчику работать через невыполненный журнал (форма регулирования полосы пропускания ).
Pub / sub обеспечивает возможность лучшей масштабируемости, чем традиционный клиент-сервер, благодаря параллельной работе, кэшированию сообщений, древовидной или сетевой маршрутизации, и т. д. Однако в определенных типах тесно связанных, крупномасштабных корпоративных сред, когда системы масштабируются до центров обработки данных с тысячами серверов, совместно использующих инфраструктуру pub / sub, существующие системы поставщиков часто теряют это преимущество; масштабируемость для общедоступных / дополнительных продуктов при высокой нагрузке в этих контекстах является исследовательской задачей.
С другой стороны, за пределами корпоративной среды парадигма pub / sub доказала свою масштабируемость до объемов, намного превышающих объемы одного центра обработки данных, обеспечивая распределенный обмен сообщениями в Интернете через такие протоколы распространения через Интернет, как RSS и Atom. Эти протоколы синдикации допускают более высокую задержку и отсутствие гарантий доставки в обмен на способность даже веб-сервера низкого уровня распространять сообщения (потенциально) на миллионы отдельных узлов-подписчиков.
Наиболее серьезные проблемы с системами публикации / подсистемы являются побочным эффектом их главного преимущества: отделения издателя от подписчика.
Публикационная / подсистема должна быть тщательно спроектирована, чтобы иметь возможность предоставлять более строгие системные свойства, которые могут потребоваться конкретному приложению, например, гарантированную доставку.
Шаблон публикации / подписки хорошо масштабируется для небольших сетей с небольшим количеством издателей и абонентские узлы и низкий объем сообщений. Однако по мере роста количества узлов и сообщений вероятность нестабильности увеличивается, ограничивая максимальную масштабируемость публикации / подсети. Примеры нестабильности пропускной способности в больших масштабах включают:
Для систем публикации / подписки, которые используют брокеров (серверы), аргумент для брокера для отправки сообщений подписчику: внутри диапазона, и могут возникнуть проблемы с безопасностью. Брокеры могут быть обмануты, отправив уведомления не тому клиенту, что усилит запросы на отказ в обслуживании для клиента. Сами брокеры могут быть перегружены, поскольку они выделяют ресурсы для отслеживания созданных подписок.
Даже с системами, которые не полагаются на брокеров, подписчик может иметь возможность получать данные, которые он не авторизован получать. Неавторизованный издатель может ввести неправильные или вредоносные сообщения в систему публикации / подписки. Это особенно верно для систем, которые рассылают или многоадресно свои сообщения. Шифрование (например, Transport Layer Security (SSL / TLS)) может предотвратить несанкционированный доступ, но не может предотвратить внесение вредоносных сообщений авторизованными издателями. Архитектуры, отличные от pub / sub, такие как системы клиент / сервер, также уязвимы для авторизованных отправителей сообщений, которые ведут себя злонамеренно.
