Взаимодействие с системой очередей сообщений 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Взаимодействие с системой очередей сообщений



Подход, применяемый в системах очередей, принципиально асинхронный. Обычно системы очередей предоставляют пользователям прикладной программный интерфейс, который удобен для использования в некотором конкретном программном окружении.

Например, программисты, использующие язык Java, могут использовать стандартный интерфейс Java Message Service (JMS): отправители (получатели) сначала привязываются к очереди, то есть идентифицируют очередь, в которую они хотят послать (из которой хотят получить) сообщение, указывая имя очереди, а затем могут приступать к отправке (получению) сообщений.

JMS – это прикладной интерфейс, его реализация возлагается на пользователей или поставщиков готовых систем. Не все МОМ-системы совместимы со службой JMS, которая может быть реализована как отдельная система или модуль внутри сервера приложений.

Транзакционные очереди

В рамках абстракции транзакционных очередей системы очередей дают гарантию, что отправленное сообщение обязательно будет доставлено приложению получателя один и только один раз, даже если сама система обмена сообщениями выйдет из строя в период между объявлением о сообщении и его доставкой. Сообщения записываются в сохранную память и, следовательно, становятся снова доступными, когда система снова становится работоспособной.

В дополнение к гарантированной доставке транзакционные очереди обеспечивают защиту от сбоев. Получатель может объединять набор чтений и уведомлений в одном атомарном действии. Атомарное действие объединяет в себе набор операций, обладающий свойством "все-или-ничего": либо все операции набора выполняются успешно, либо не выполняется ни одна операция. В случае возникновения сбоя в момент, когда еще не все операции из атомарного набора выполнились, происходит откат всех завершенных действий, что соответствует обратному помещению сообщения в очередь, так что оно может быть снова прочитано тем же приложением, либо каким-нибудь другим. С точки зрения отправителя транзакционность очереди означает, что сообщения, отправляемые внутри атомарного набора, записываются системой в сохранную память и становятся видимыми для доставки только тогда, когда выполнение атомарного набора операций заканчивается.

Следовательно, откат уведомления о сообщении просто приводит к удалению сообщения из сохранной памяти.

Брокеры сообщений

При комплексной интеграции прикладных систем особенно важно автоматизировать взаимодействие цепочек поставок, то есть передач информации от одной прикладной системы другой. Практическая жизнь сложилась так, что системы автоматизации, базы данных, форматы данных у всех предприятий разные.

Автоматизация цепочки поставок – это сведение воедино всех таких разобщенных систем. Что еще хуже, при комплексной интеграции приходится сталкиваться со многими нетехническими проблемами: каждая включаемая в цепочку система обычно принадлежит и эксплуатируется разными подразделениями компании. Каждое подразделение управляется автономно и выполняет много специфических функций, которые не всегда согласуются с тем, что должно получиться при интеграции. Однако если не автоматизировать цепочки поставок, многие операции на стыках систем будут выполняться вручную.

Традиционные системы на базе RPC и системы очередей создают между приложениями соединения типа "точка-точка". Часто возникающая при их использовании проблема заключается в том, что при таком взаимодействии ответственность за определение получателя сообщения ложится на отправителя. В определенных случаях эта схема адресации становится трудно управляемой, поскольку число отправителей и получателей постоянно растет, а окружение, в котором работает система, становится более динамичным. Если отправителю потребуется начать взаимодействовать с новой системой, его приложение должно быть изменено. Снять подобные ограничения удается с помощью брокеров сообщений, которые действуют как посредники между системными сущностями. Брокеры сообщений обеспечивают гибкую маршрутизацию и другие необходимые для интеграции приложений качества. В сочетании с асинхронным обменом информацией – это наиболее пригодный подход к решению проблемы комплексной интеграции приложений отдельных предприятий.

Брокеры сообщений забирают задачу определения пути доставки сообщения у отправителя и передают ее ядру системы. Имея брокер сообщений, пользователи могут выбрать такую прикладную логику, которая для каждого сообщения идентифицирует очередь, в которую сообщение должно быть доставлено. Это позволяет отправителям не указывать, кто будет получателем сообщения. Брокер сообщений, выполняя правила, заданные пользователем, сам определит получателя, что значительно упрощает схему взаимодействия прикладных компонентов системы и их внутреннюю структуру. Правила определения единственного из потенциальных получателей сообщения конкретного вида и содержания от конкретного отправителя сосредотачиваются в единственном месте системы, что облегчает процесс их модификации, если она потребуется.

Правила маршрутизации обычно кодируются на специальном языке, каждое правило содержит логическое условие, зависящее от значений данных, находящихся в доставляемом сообщении. Логика может определяться в брокере сообщений, либо на уровне очереди. Если она определяется в брокере, то относится ко всем сообщениям, которые затем соответствующим образом маршрутизируются. Если логика связана с очередью, она определяет, в получении каких сообщений эта очередь заинтересована.

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

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

Например, еще одной причиной привязки логики к очереди может быть потребность определить "правила преобразования содержания". Различные приложения, интегрируемые в единую систему, могут иметь разные форматы данных (могут, например, использоваться разные единицы измерения физических величин). Определяя правила преобразования содержания и ассоциируя их с очередью, можно проводить подобные преобразования в брокере, освобождая каждое приложение от выполнения такой работы. Приписывая разные преобразования разным очередям, их удается приспособить к потребностям разных приложений, не модифицируя.

1.6.1. Модель взаимодействия "публикация/подписка"

Благодаря управлению маршрутизацией, брокеры сообщений могут поддерживать различные модели взаимодействия, основанные на обмене сообщениями. Наиболее известной из них является парадигма "публикация/подписка": приложения взаимодействуют, обмениваясь сообщениями, характеризуемыми типом и набором параметров, но отправляющие сообщения приложения не указывают получателей. Вместо этого они просто публикуют сообщение в промежуточном слое, управляющем взаимодействием. По этой причине приложения, посылающие сообщения, называются "издателями". Если приложение заинтересовано в получении сообщений данного типа, оно должно подписаться в системе "публикация/подписка", регистрируя свой интерес.

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

В модели "публикация/подписка" подписчики могут определять заинтересовавшие их сообщения двумя способами. Во-первых, они могут указывать тип сообщений (например, "Новый заказ"). В простейших случаях пространство именования типов довольно ограниченно и определяется символьной строкой. Более сложные системы допускают вводить структурные имена типов на основе иерархии типов/подтипов произвольной глубины. Используя структурированные типы, подписчики могут не только регистрировать свой интерес к сообщениям, имеющим некоторый тип, и подписываться на них, но также подписываться на сообщения, тип которых является прародителем в иерархии типов.

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



Поделиться:


Последнее изменение этой страницы: 2017-02-19; просмотров: 307; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 54.81.58.140 (0.007 с.)