Технология Клиент-Сервер 2002'3
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Сервис оповещений (Notification Service) CORBA**

Cервис оповещений является развитием Сервиса Событий (Event Service), о котором было кратко рассказано в статье «Использование callback-вызовов и сервисов событий в CORBA» (Технология Клиент-Сервер №3 за 2000 г., http://www.k-press.ru/cs/ 2000/3/corba/corba_callback.asp). Поскольку все, что было в Event Service, перешло в Notification Service, мы не будем повторять то, о чем уже говорилось, и уделим основное внимание новым возможностям, которые предоставляет Notification Service. В настоящий момент принято объединять Сервисы Событий и Оповещений (часто пишут Event/Notification Service).

Вместо вступления

За прошедшие два-три года ситуация с CORBA в интересующем нас направлении несколько изменилась, а именно, появилась спецификация Сервиса Сообщений CORBA (Messaging Service). В связи с этим, имеет смысл рассмотреть сходства и различия, а также области применения соответственно Messaging- и Event/Notification-сервисов.

И тот, и другой могут решать некоторые общие проблемы, а именно:

• изоляция источников событий и их получателей для большей гибкости управления процессом передачи событий;

• выполнение асинхронных (в некотором смысле) вызовов. Под «асинхронным вызовом» здесь понимается вызов, когда поток (thread), в котором выполнена команда посылки сообщения, не блокируется до получения оповещения о завершенности действия. Часто термин «асинхронный» используется и в другом значении, о чем разговор впереди;

• посылка сообщений не одному, а нескольким получателям одновременно;

• использование буферизации для достижения большей производительности;

• настройка режима взаимодействия (Quality-of-Service, QoS в терминах CORBA);

• фильтрация событий с отсеиванием ненужных.

Тем не менее, основные задачи, для решения которых используются оба сервиса, достаточно сильно различаются, и выбор наиболее подходящего сервиса в каждом конкретном случае не вызывает труда (разумеется, мы предполагаем, что доступна реализация как того, так и другого). Принципиальные отличия состоят в следующем:

• Event/Notification требует, чтобы участвующие в обмене сообщениями CORBA-объекты были активны, т.е. приложения, в которых созданы и активизированы эти CORBA-объекты, работали. Это похоже на телефонную связь – участники разговора «держат трубки в руках». В отличие от такого подхода, Messaging Service позволяет осуществлять обмен сообщениями в режиме «почты»: приложение-автор сообщения посылает его промежуточному звену («почтовому ящику»); приложение-получатель, будучи запущенным позднее, получает это сообщение и, возможно, посылает ответ.

• Event/Notification Service требует наличия предварительно созданной – и в этом смысле «статической» – инфраструктуры передачи сообщений, основой которой являются каналы (channels). Messaging Service позволяет обеспечить гораздо более гибкую систему маршрутизации.

• Messaging Service, в отличие от Event/Notification Service, позволяет посылать сообщения в контексте распределенных транзакций (нескольких транзакций, в общем случае). Впрочем, «надежный» (reliable) механизм обеспечения соединений и доставки сообщений часто позволяет обойтись без формального использования транзакций.

• Использовать Event/Notification Service значительно проще, чем Messaging Service.

Виды сообщений в Notification Service

Event Service предусматривал наличие двух типов событий – типизированных (typed) и нетипизированных (untyped)...

<...>

Как и следует ожидать, спецификация Notification Service предусматривает стандартные интерфейсы, которые позволяют создавать и анализировать нужные структурированные события.

В Notification Service можно выделить два вида каналов:

• канал для передачи типизированных событий (TypedEventChannel).

• канал для передачи нетипизированных и структурированных событий (EventChannel).

<...>

Стандартные объекты Notification Service

Помимо каналов, основными стандартными объектами Event Service (а, следовательно, и Notification Service) являлись Admin-объекты (как фабрики Proxy-объектов) и сами Proxy-объекты, которые и обеспечивали большую часть функциональности сервиса. Применительно к этим объектам в Notification Service по сравнению с Event Service произошли большие изменения:

• каналы Notification Service могут иметь несколько Admin-объектов как на стороне поставщиков событий, так и на стороне их получателей;

• с каждым из таких объектов сопоставлен целочисленный уникальный идентификатор;

• с Admin-объектами могут быть сопоставлены фильтры сообщений.

Стиль EventService состоит в том, что различные виды Proxy-объектов определяются не только для push- и pull-модели, но и для каждого вида событий (типизированное или нетипизированное). Этот стиль сохранен в Notification Service, что автоматически приводит к появлению отдельных Proxy-объектов для новых типов событий – структурированных событий и их последовательностей. Итак, в Notification Service присутствуют 16 видов Proxy-объектов – так как существуют 2 модели (push- и pull), 2 вида участников – поставщики и получатели событий – и 4 вида событий.

С Proxy-объектами, как и с Admin-объектами, могут быть сопоставлены фильтры, которые позволяют отсеивать те события, в получении которых потребитель не заинтересован.

Кроме того, в Notification Service появились дополнительные стандартные объекты, связанные с фильтрацией сообщений и QoS – например, Filter, MappingFilter, FilterFactory, FilterAdmin, QoSAdmin, AdminPropertiesAdmin, а также служебные интерфейсы, связанные с поддержкой информации о метаданных – например, NotifyPublish, NotifySubscribe и др. О некоторых из них кратко будут рассказано ниже.

<...>

Quality-of-Service

Quality-of-Service (обычно используется аббревиатура QoS) в технологии CORBA обеспечивает некий универсальный подход по управлению элементами инфраструктуры CORBA. Естественно, для разных элементов и сервисов CORBA предусмотрены свои параметры настройки, поэтому здесь мы будем говорить только о QoS применительно к Notification Service.

Надо сказать, что подход к организации QoS в Notification Service отличается от стандартного подхода CORBA. Параметры, используемые при этом, не являются типами, производными от CORBA::Policy. Вместо этого используются целочисленные константы, а также «свойства QoS», которые представляют собой структуру из двух полей – имени поля (типа string) и его значения (типа any). Тот же подход используется для так называемого администрирования, которое предназначено для решения сходных с QoS задач, но имеет свои особенности:

module CosNotification
{
  typedef Istring PropertyName;
  typedef any PropertyValue;

  struct Property
  {
    PropertyName name;
    PropertyValue value;
  };
  typedef sequence<Property> PropertySeq;

  typedef PropertySeq QoSProperties;
  typedef PropertySeq AdminProperties;
  ...
  const string EventReliability = “EventReliability”;
  const short BestEffort = 0;
  const short Persistent = 1;

  const string Priority = “Priority”;
  const short LowestPriority = -32767;
  const short HighestPriority = 32767;
  const short DefaultPriority = 0;
  ...
};

Основными компонентами QoS применительно к Notification Service являются следующие:

• собственно свойства QoS;

• методы, которые позволяют задавать (получать, контролировать) эти свойства на уровне различных компонентов Notification Service, а именно, на уровне канала, Admin-объектов, Proxy-объектов и самих событий.

Задание опций QoS на различных уровнях иерархии объектов – обычный подход CORBA. Например, классические политики (Policies) QoS CORBA можно задавать на уровне ORB, на уровне потока (thread) в ORB и на уровне конкретной объектной ссылки. При этом значения, заданные на более высоком уровне, применяются и на более низких уровнях – в случае, если эти значения на этих более низких уровнях не были переопределены. Точно также обстоит дело и с Notification Service. Наиболее высоким уровнем является канал, затем идут Admin-объекты, затем – Proxy-объекты и, наконец, сами события. Разумеется, не все опции могут быть заданы на всех возможных уровнях и для всех объектов на одном уровне. Например, Proxy-объекты для поставщиков и получателей событий отличаются по множеству свойств QoS, которые к ним применимы.

Важной проблемой при использовании QoS для Notification Service является следующая: весь путь прохождения события можно разбить на три этапа: 1) от поставщика к каналу; 2) в самом канале; 3) от канала к получателю. На разных этапах задействованы разные объекты сервиса, т.е. возникает возможность конфликта между различными настройками QoS. В общем случае все возможные конфликты не могут быть разрешены автоматически, средствами самой реализации, и обязанность задать соответствующие друг другу настройки QoS для различных объектов ложится на программиста.

Давайте рассмотрим основные свойства QoS...

<...>

Средства задания и контроля
свойств QoS

Для задания соответствующих свойств на нужном уровне в Notification Service предусмотрен интерфейс QosAdmin:

module CosNotification
{
  ...
  typedef string Istring;
  typedef Istring PropertyName;
  typedef any PropertyValue;

  struct PropertyRange
  {
    PropertyValue low_val;
    PropertyValue high_val;
  };

  struct NamedPropertyRange
  {
    PropertyName name;
    PropertyRange range;
  };

  typedef sequence<NamedPropertyRange> NamedPropertyRangeSeq;

  interface QoSAdmin
  {
    QoSProperties get_qos();
    void set_qos (in QoSProperties qos)
      raises (UnsupportedQoS);
    void validate_qos (
      in QoSProperties required_qos,
      out NamedPropertyRangeSeq available_qos)
      raises (UnsupportedQoS);
  };
};

Как вы уже видели ранее, этот интерфейс объявляется в качестве базового для тех типов (интерфейсов), которые поддерживают использование QoS. Все эти методы могут вызываться для канала, группы Proxy-объектов или отдельного Proxy-объекта.

Назначение методов get_qos() и set_qos() очевидно – первый возвращает последовательность структур, которые описывают определенные для данного объекта свойства QoS и их значения, второй – задает нужные свойства. Интереснее дело обстоит с методом validate_qos().

Как следует из его названия, главное назначение этого метода – не задать свойства QoS, а проверить, допустимым ли для данного объекта является набор свойств и их значений, заданных первым аргументом метода. Если параметры заданы верно, то в качестве выходного параметра возвращается список дополнительных свойств QoS вместе с диапазоном их значений, которые могут быть использованы в данном случае.

Ранее упоминался метод validate_event_qos(). Этот метод очень похож на метод validate_qos(), но применим только к Proxy-объектам (ProxyConsumer и ProxySupplier) при передаче структурированных событий. Для этих событий некоторые свойства QoS могут быть заданы прямо в заголовке события.

<...>

Одним из наиболее интересных расширений (по сравнению с Event Service) является возможность фильтрации событий. Поскольку за доставку и получение событий реально отвечают Proxy-объекты (как на стороне поставщика, так и на стороне получателя), то фильтры работают именно на этом уровне. Для удобства работы Notification Service позволяет выполнить «группировку» Proxy-объектов с целью задания всем объектам в одной группе общих свойств (свойств QoS или фильтров). Для этой цели используются фабрики Proxy-объектов, т.е. Admin-объекты.

Фильтры можно разделить на две группы:

• фильтры для собственно фильтрации событий (интерфейс Filter) и

• фильтры для управления процессом доставки событий (интерфейс MappingFilter).

Эти группы фильтров мы будем рассматривать отдельно.

Смысл фильтрации событий состоит в том, что для Proxy-объекта (на стороне поставщика и/или получателя) задается набор выражений, написанных на специальном языке. В этих выражениях могут появляться имена полей событий, арифметические или логические операции, константы, переменные, а также специальные методы. За основу языка описания фильтров взят язык, используемый в Trader Service CORBA. Напоминаем (или сообщаем читателю), что Trader Service – один из стандартных сервисов CORBA, который позволяет клиенту получить из специальной базы данных одну или несколько объектных ссылок на такие серверные CORBA-объекты, которые удовлетворяют определенным требованиям. Для этого с объектными ссылками перед помещением их в базу данных сопоставляются атрибуты со значениями. Запрос клиента к такой базе данных чем-то напоминает SQL-запрос типа SELECT с развитой WHERE-частью. Определить фильтр – это задать выражение, сходное с WHERE-выражением оператора SELECT.

Язык задания таких выражений будет кратко рассмотрен в следующем разделе.

Интерфейсы, связанные с фильтрацией событий, объявлены в модуле CosNotifyFilter.

Некоторые вспомогательные
типы данных

Каждое выражение (в виде строки), задающее критерий фильтрации, вместе со списком событий, к которому применимо это выражение, называют «выражением для задания ограничения» (Constraint Expression). Фильтр задается с помощью последовательности таких выражений...

<...>

Notification Service является простым и удобным в использовании средством, которое позволяет существенно упростить решение задач, часто встречающихся в реальных условиях. В первую очередь об использовании Notification Service нужно подумать тогда, когда в вашей программе возникает необходимость организации callback-вызовов и рассылки сообщений от одного источника ко многим потребителям, особенно если инфраструктура подсистемы передачи сообщений достаточно статична, а источники и получатели могут подключаться к каналам информации и отключаться от них в произвольные моменты времени.

На рынке присутствуют несколько реализаций Notification Service. Одной из самых качественных и интересных является недавно появившаяся реализация от Borland (эта реализация выполнена на Java и входит в состав Borland Enterprise Server под именем VisiNotify). Она имеет несколько уникальных особенностей, таких, как возможность передачи объектов типа valuetype, а также возможность регистрации EJB-компонентов как получателей структурированных событий, что обеспечивает очень высокий уровень интеграции CORBA и J2EE и, как следствие, предоставляет разработчику дополнительные возможности повышения эффективности и масштабируемости приложений.

Прочитать статью полностью вы можете в печатной версии журнала

Copyright © 1994-2016 ООО "К-Пресс"