Подписавшийся на определенный тип сообщений клиент, может получить имеющиеся в шине сообщения, после получения сообщения клиентов, в шине оно не хранится. При получении сообщения клиент может указать индекс, чтобы получить не первое сообщение в очереди, очередь сообщений сортируется с учетом приоритета и времени получения сообщения. Также можно указать теги которые должно иметь сообщение. Для получения сообщений из шины можно также воспользоваться одним из доступных на данный момент интерфейсов, WCF [10] или REST [11].
При использовании подписки с опцией callback, доставка сообщений выполняется по инициативе шины, на указанный у клиента адрес, выбранным способом.
Для управления потоками сообщений разработано административное приложение, которое позволяет:
- просматривать и редактировать типы сообщений;
- просматривать и редактировать клиентов;
- просматривать и редактировать подписки;
- просматривать и редактировать очередь сообщений;
- просматривать и редактировать настройки ведения и сжатия статистики.
Одним из возможных вариантов взаимодействия с шиной является использование платформы WCF для вызова методов предоставляемых интерфейсом шины. На данный момент этот интерфейс наиболее полно охватывает возможности шины. WCF интерфейс позволяет:
- передавать сообщения в шину;
- получать сообщения из шины;
- подписывать клиентов на типы сообщений.
Еще одним вариантом взаимодействия с шиной является выполнение запросов по протоколу HTTP в стиле REST. REST интерфейс позволяет:
- передавать сообщения в шину;
- получать сообщения из шины.
1.3 Анализ существующих решений
Сервисная шина Mule ESB
Mule - система маршрутизации сообщений, позволяющая обеспечить обмен данными между различными системами. Mule относится к свободному программному обеспечению с открытым кодом, распространяемому по CPAL-лицензии. По сравнению с аналогичными решениями Mule имеет ряд существенных преимуществ:
- возможность связывания компонентов из различных программных сред (framework);
- повторное использовать компонентов;
- компоненты не требуют изменений кода непосредственно под выполнение в Mule, а специфические программные API отсутствуют;
- бизнес-логика полностью отделена от логики обмена сообщениями;
- поддержка любого формата сообщений, например, это может быть сообщение SOAP или даже двоичный образ файла;
- отсутствие ограничений на приложения по архитектуре, например, передача только XML сообщений или организация WSDL-сервисов;
- развертывание в разнообразных топологиях;
- обеспечение безопасности, масштабируемости и адаптивности к изменениям;
- отсутствие протекционизма и блокировок от/на конкретных производителей.
Вне зависимости от технологий, используемых приложениями (JMS, Web-сервисы, JDBC, HTTP и пр.) Mule позволит обеспечить связь между ними, причем не имеет значения, размещены ли они в одной виртуальной машине или распределены в Интернет. Построенная на основе Enterprise Service Bus (ESB) архитектуры данный программный продукт выступает в качестве транзитной системы для «перевозки» данных, что позволяет приложениям, находящимся в интрасети или Интернет связываться друг с другом.
Архитектура Mule позволяет разделить уровень бизнес-логики от транспортного уровня, т.е. обработку полезной составляющей сообщения от его передачи и преобразования, предоставляя таким образом достаточную гибкость в организации архитектуры приложений и упрощая саму настройку бизнес-логики. Имеется возможность разворачивать Mule в различных топологиях, например, иметь несколько экземпляров Mule распределенных по сети. Такой подход полезен на случай отказа, если один экземпляр Mule становится недоступным, другой экземпляр Mule берет на себя его сообщения. Аналогичный подход можно применить для балансировки нагрузки [12].
Сервисная шина Apache ServiceMix
Apache ServiceMix - пакет для создания композитных приложений, базирующийся на концепции Enterprise Service Bus и комбинирующий сервис-ориентированную архитектуру и событийно-ориентированную архитектуру. ServiceMix реализует также спецификацию Java Business Integration (JBI).
Основными функциями сервисной шины Apache ServiceMix являются:
- надежный обмен сообщениями с Apache ActiveMQ;
- шаблоны обмена сообщениями, маршрутизации и интеграции предприятия с Apache Camel;
- веб-сервисы WS? * и RESTful с Apache CXF;
- серверная среда на основе OSGi от Apache Karaf.
Также имеется возможность установить дополнительные пакеты, поддерживающие следующие функции:
- BPM engine через Activiti;
- полная поддержка JPA через Apache OpenJPA;
- управление транзакциями XA через JTA через Apache Aries;
- унаследованная поддержка стандарта JBI (устарела после серии ServiceMix 3.x) через ЯМР Apache ServiceMix, который включает в себя богатый API событий, обмена сообщениями и аудита.
Приложения для ServiceMix могут быть построены с использованием:
- план OSGi;
- OSGi Декларативные услуги;
- Spring DM [13].
Сервисная шина OpenESB
OpenESB - это сервисная шина с открытым исходным кодом. Данный программный продукт можно использовать как платформу для интеграции корпоративных приложений и сервис-ориентированной архитектуры. OpenESB позволяет интегрировать устаревшие системы, внешние и внутренне системы и новые разработки.
Фреймворк состоит из облегченной реализации JBI на Java. Эта реализация не зависит от контейнера и может работать на любой платформе и любом контейнере. В дополнение к тому, что инфраструктура OpenESB легка, она также надежна и легко масштабируется. Система встроена в виртуальную машину Java и взаимодействует с другими экземплярами инфраструктуры через компоненты Binding. Эта архитектура соответствует новым облачным архитектурам и позволяет легко развертывать и управлять в очень сложных инфраструктурах. Каркас полностью управляем с помощью любого инструмента на основе JMX, такого как Jconsole, или более сложных инструментов, таких как Opsview или Nagios.
Платформа реализует виртуальную шину, известную как нормализованный маршрутизатор сообщений (NMR). Это мощный асинхронный интеллектуальный канал связи между компонентами.
Спецификация JBI определяет два типа компонентов: ядро служб (SE) и компонент привязки (BC). SE и BC реализуют один и тот же контракт интерфейса, однако ведут себя по-разному:
- Связующие компоненты действуют как интерфейс между внешней средой и сервисной шиной, являющиеся способными на генерацию данных (сообщений) шины при получении стимулов от внешнего источника или на генерацию внешнего действия/взаимодействия в ответ на сообщение, полученное от сервисной шины.
- Сервисные движки получают сообщения с шины и отправляют сообщения на шину. Движки не имеют прямого контакта с внешним миром. Они полагаются на шину для взаимодействия с другими компонентами, будь то обязательные компоненты или другие сервисные механизмы [14].
Сервисная шина OW2 Petals
Petals ESB - это ESB с открытым исходным кодом. Данный продукт является инструментом для реализации сервис-ориентированной архитектуры (SOA). Он является стандартным, модульным и физически распределенным для адаптации к крупномасштабным инфраструктурам.
Petals ESB основана на отраслевой спецификации JBI (JSR 208). Основанный на стандартах, он также поддерживает стандарты SOA, такие как возможности BPMN и шаблоны корпоративной интеграции.
Инфраструктура фрактального развертывания, подключаемые компоненты JBI и лицензирование с открытым исходным кодом делают его модульным и настраиваемым. Оригинальность Petals заключается в реализации высокораспределенной топологии [14].
1.4 Анализ RabbitMQ
RabbitMQ ? это брокер сообщений. Его основная цель ? принимать и отдавать сообщения. RabbitMQ позволяет взаимодействовать различным программам при помощи протокола AMQP. RabbitMQ является отличным решением для построения SOA (сервис-ориентированной архитектуры) и распределением отложенных ресурсоемких задач.
В RabbitMQ, а также обмене сообщениями в целом, используется следующая терминология:
- Producer ? программа, отправляющая сообщения;
- Queue ? имя очереди. Она существует внутри RabbitMQ. Хотя сообщения проходят через RabbitMQ и приложения, хранятся они только в очередях. Очередь не имеет ограничений на количество сообщений, она может принять сколь угодно большое их количество ? можно считать ее бесконечным буфером. Любое количество поставщиков может отправлять сообщения в одну очередь, также любое количество подписчиков может получать сообщения из одной очереди;
- Consumer ? программа, принимающая сообщения. Обычно подписчик находится в состоянии ожидания сообщений.
Поставщик, подписчик и брокер не обязаны находиться на одной физической машине (обычно они находятся на разных).
Возможное взаимодействие этих трех компонентов представлено на рис. 1.3, где P - Producer (программа-отправитель), Q - Queue (очередь), C - Consumer программа-получатель сообщения).
Рисунок 1.3. Компоненты RabbitMQ
RabbitMQ имеет много возможностей и преимуществ, рассмотрим наиболее важные из них.
Открытый исходный код. Первоначально разработанный в партнёрстве LShift, LTD и Cohesive FT как RabbitMQ Technologies, RabbitMQ теперь находится в собственности Pivotal Software Inc. и выпускается под лицензией Mozilla Public License. Будучи проектом с открытым исходным кодом, написанным на Erlang, RabbitMQ обладает свободой и гибкостью, одновременно используя мощность Pivotal, стоящую за ним как за продуктом. Разработчики и инженеры из сообщества RabbitMQ могут вносить улучшения и дополнения, а Pivotal может предлагать коммерческую поддержку и стабильный дом для постоянного вызревания продукта.
Нейтральность к платформе и производителю. Т.к. брокер сообщений, который реализует нейтральную к платформам и производителям спецификацию Advanced Message Queuing Protocol (AMQP), имеются клиенты, доступные практически для любого языка программирования и на всех основных платформах.
Лёгкий вес. Он является легковесным, требуя менее чем 40 МБ ОЗУ для исполнения центрального ядра приложения RabbitMQ совместно с подключаемыми модулями, такими как UI Управления. Однако, важно отметить, что добавление сообщений в очередь может увеличить потребление памяти и делает это.
Библиотеки клиента для большинства современных языков. Обладая библиотеками клиента, имеющими целью основные современные языки программирования на множестве платформ, RabbitMQ предлагает привлекательный брокер для его программирования. Не существует привязки к какому-либо производителю или языку при выборе того на как вы будете разрабатывать программы, которые будут общаться с RabbitMQ. RabbitMQ предоставляет полезный мост, который делает возможным для таких языков, как Java, Ruby, Python, PHP, JavaScript и C# совместно использовать данные в различных операционных системах и средах.
Гибкость в контроле компромиссов обмена сообщениями. RabbitMQ предоставляет гибкость в контроле необходимых компромиссов надёжности обмена сообщениями с пропускной способностью сообщений и производительностью. Так как нет "одного размера под все" типы приложений, сообщения могут назначать должны ли они сохраняться на диск перед отправкой и, если они настроены в кластере, очереди могут быть настроены на высокую доступность, распространяясь на множество серверов и гарантируя что сообщения не утратятся в случае отказа сервера.
Подключаемые модули для сред с высокой латентностью. Т.к. не все сетевые топологии и архитектуры одинаковы, RabbitMQ предназначается для обмена сообщениями в средах с низкой латентностью, а подключаемые модули для окружений с высокой латентностью, например, для Всемирного интернета.
Подключаемые модули сторонних разработчиков. Как центральный пункт для интеграции приложений, RabbitMQ предоставляет гибкую систему подключаемых модулей (plugin). Например, имеются подключаемые модули сторонних разработчиков для сохранения сообщений непосредственно в базах данных при помощи записей RabbitMQ напрямую в базу данных.
Уровни безопасности. В RabbitMQ безопасность предоставляется на множестве уровней. Клиентские соединения могут быть обеспечены безопасностью усилением взаимодействия только через SSL и удостоверением сертификата клиента. Доступ пользователя может управляться на уровне виртуального хоста, предоставляя изоляцию сообщений и ресурсов на высоком уровне. Кроме того, доступ к возможностям настройки, чтение из очередей и запись в обмен управляются соответствиями шаблонов регулярных выражений (regex). Наконец, для интеграции с внешними системами аутентификации, такими как LDAP, могут применяться подключаемые модули [15].
Многие достоинства RabbitMQ, включая его гибкость, проистекают из спецификации AMQP. В отличии от таких протоколов как HTTP и SMTP, спецификация AMQP определяет не только некий сетевой протокол, но также и службы и поведение стороны сервера.
Существует три абстрактных компонента в программном обеспечении брокера, которые определяют поведение маршрутизации сообщений:
- Exchange (Обмен): Этот компонент брокера обмена сообщениями осуществляет маршрутизацию сообщений в очереди;
- Queue (очередь): структура данных на диске или в оперативной памяти, которая сохраняет сообщения;
- Binding (связывание): некое правило, которое сообщает имеющемуся обмену в какой из очередей эти сообщения должны сохраняться.