Advanced Message Queuing Protocol ( AMQP ) — это открытый стандартный протокол прикладного уровня для промежуточного программного обеспечения, ориентированного на сообщения . Определяющими характеристиками AMQP являются ориентация сообщений, организация очередей, маршрутизация (включая «точка-точка» и «публикация-подписка» ), надежность и безопасность. [1]
AMQP предписывает поведение поставщика сообщений и клиента в той степени, в которой реализации от разных поставщиков являются совместимыми , так же, как SMTP , HTTP , FTP и т. д. создали совместимые системы. Предыдущие стандартизации промежуточного программного обеспечения происходили на уровне API (например, JMS ) и были сосредоточены на стандартизации взаимодействия программиста с различными реализациями промежуточного программного обеспечения, а не на обеспечении взаимодействия между несколькими реализациями. [2] В отличие от JMS, который определяет API и набор поведений, которые должна предоставлять реализация обмена сообщениями, AMQP является протоколом уровня проводов . Протокол уровня проводов представляет собой описание формата данных, которые передаются по сети в виде потока байтов . Следовательно, любой инструмент, который может создавать и интерпретировать сообщения , которые соответствуют этому формату данных, может взаимодействовать с любым другим совместимым инструментом независимо от языка реализации.
AMQP — это бинарный протокол прикладного уровня, разработанный для эффективной поддержки широкого спектра приложений обмена сообщениями и шаблонов связи. Он обеспечивает управляемую потоком, [3] ориентированную на сообщения связь с гарантиями доставки сообщений, такими как at-most-once (когда каждое сообщение доставляется один раз или никогда), at-least-one (когда каждое сообщение наверняка будет доставлено, но может быть доставлено несколько раз) и exact-one (когда сообщение всегда будет доставлено и доставлено только один раз), [4] и аутентификацию и/или шифрование на основе SASL и/или TLS . [5] Он предполагает базовый надежный протокол транспортного уровня, такой как Transmission Control Protocol (TCP). [6]
Спецификация AMQP определена на нескольких уровнях: (i) система типов, (ii) симметричный асинхронный протокол для передачи сообщений от одного процесса к другому, (iii) стандартный расширяемый формат сообщений и (iv) набор стандартизированных, но расширяемых «возможностей обмена сообщениями».
AMQP был создан в 2003 году Джоном О'Хара в JPMorgan Chase в Лондоне . [1] [7] AMQP был задуман как совместная открытая работа. Первоначальный дизайн был разработан JPMorgan Chase с середины 2004 по середину 2006 года, и компания заключила контракт с iMatix Corporation на разработку брокера C и документации протокола. В 2005 году JPMorgan Chase обратилась к другим фирмам с целью формирования рабочей группы, в которую вошли Cisco Systems , IONA Technologies , iMatix, Red Hat и Transaction Workflow Innovation Standards Team (TWIST). В том же году JPMorgan Chase объединилась с Red Hat для создания Apache Qpid , изначально на Java, а вскоре и на C++. Независимо от этого RabbitMQ был разработан на Erlang компанией Rabbit Technologies, а затем последовали реализации от Microsoft и StormMQ.
Рабочая группа выросла до 23 компаний, включая Bank of America , Barclays , Cisco Systems, Credit Suisse , Deutsche Börse , Goldman Sachs , HCL Technologies Ltd , Progress Software , IIT Software, INETCO Systems Limited, Informatica (включая 29 West), JPMorgan Chase, Microsoft Corporation , my-Channels, Novell , Red Hat , Software AG , Solace Systems , StormMQ, Tervela Inc. , TWIST Process Innovations ltd, VMware (которая приобрела Rabbit Technologies) и WSO2 .
В 2008 году Питер Хинтйенс , генеральный директор и главный разработчик программного обеспечения iMatix, написал статью под названием «Что не так с AMQP (и как это исправить)» [8] и распространил ее среди рабочей группы, чтобы предупредить о надвигающемся сбое, выявить проблемы, замеченные iMatix, и предложить способы исправления спецификации AMQP. К тому времени iMatix уже начала работу над ZeroMQ . В 2010 году Хинтйенс объявил, что iMatix покинет рабочую группу AMQP и не планирует поддерживать AMQP/1.0 в пользу значительно более простого и быстрого ZeroMQ. [9]
В августе 2011 года рабочая группа AMQP объявила о своей реорганизации в секцию членов OASIS . [10]
AMQP 1.0 был выпущен рабочей группой AMQP 30 октября 2011 года на конференции в Нью-Йорке. На этом мероприятии Microsoft, Red Hat, VMware , Apache, INETCO и IIT Software продемонстрировали программное обеспечение, работающее на протоколе, в демонстрации взаимодействия. На следующий день, 1 ноября 2011 года, было объявлено о формировании технического комитета OASIS [11] для продвижения этой версии AMQP 1.0 через международный процесс открытых стандартов. Первый проект от OASIS был выпущен в феврале 2012 года [12] , изменения по сравнению с опубликованным рабочей группой были ограничены правками для улучшения ясности (без функциональных изменений). Второй проект был выпущен для публичного обзора 20 июня (снова без функциональных изменений), [13] и AMQP был одобрен в качестве стандарта OASIS 31 октября 2012 года. [14]
OASIS AMQP был одобрен для выпуска в качестве международного стандарта ISO и IEC в апреле 2014 года. [15] AMQP 1.0 был вынесен на голосование через Объединенный технический комитет по информационным технологиям (JTC1) Международной организации по стандартизации (ISO) и Международной электротехнической комиссии (IEC). Одобренному представлению OASIS AMQP было присвоено обозначение ISO/IEC 19464.
Предыдущие версии AMQP: 0-8, опубликованная в июне 2006 г., 0-9, опубликованная в декабре 2006 г., 0-10, опубликованная в феврале 2008 г. [16] и 0-9-1, опубликованная в ноябре 2008 г. Эти более ранние выпуски существенно отличаются от спецификации 1.0. [17] [18]
Хотя AMQP зародился в сфере финансовых услуг, он имеет общую применимость к широкому спектру проблем промежуточного программного обеспечения .
AMQP определяет самоописываемую схему кодирования, позволяющую интероперабельное представление широкого спектра часто используемых типов. Он также позволяет аннотировать типизированные данные дополнительным значением, [19] например, конкретное строковое значение может быть аннотировано так, чтобы его можно было понять как URL . Аналогично значение карты, содержащее пары ключ-значение для 'name', 'address' и т. д., может быть аннотировано как представление типа 'customer'.
Система типов используется для определения формата сообщения, позволяющего выражать и понимать стандартные и расширенные метаданные обрабатывающими сущностями. Она также используется для определения примитивов связи, посредством которых сообщения обмениваются между такими сущностями, т. е. тел фреймов AMQP .
Базовой единицей данных в AMQP является кадр . Определено девять тел кадров AMQP, которые используются для инициирования, управления и прекращения передачи сообщений между двумя одноранговыми узлами. Это:
Протокол связи лежит в основе AMQP.
Тело кадра присоединения отправляется для инициирования новой ссылки; отсоединения — для разрыва ссылки. Ссылки могут быть установлены для получения или отправки сообщений.
Сообщения отправляются по установленному каналу связи с использованием кадра передачи . Сообщения по каналу связи передаются только в одном направлении.
Переводы подчиняются схеме управления потоком на основе кредита, управляемой с помощью кадров потока . Это позволяет процессу защитить себя от перегрузки слишком большим объемом сообщений или, проще говоря, разрешить подписной ссылке извлекать сообщения по мере необходимости. [20]
Каждое переданное сообщение в конечном итоге должно быть урегулировано . Урегулирование гарантирует, что отправитель и получатель согласуют состояние передачи, предоставляя гарантии надежности. Изменения в состоянии и урегулирование для передачи (или набора передач) передаются между одноранговыми узлами с помощью фрейма размещения . Различные гарантии надежности могут быть реализованы таким образом: at-most-once, at-least-once и exact-once. [21]
Несколько ссылок в обоих направлениях могут быть сгруппированы в сеанс . Сеанс — это двунаправленный последовательный разговор между двумя пирами, который начинается с кадра начала и заканчивается кадром конца . Соединение между двумя пирами может иметь несколько сеансов, мультиплексированных по нему, каждый из которых логически независим. Соединения инициируются открытым кадром, в котором выражаются возможности отправляющего пира, и завершаются кадром закрытия .
AMQP определяет как голое сообщение ту часть сообщения, которая создается отправляющим приложением. Это считается неизменяемым, поскольку сообщение передается между одним или несколькими процессами.
Обеспечение неизменяемости сообщения, отправленного приложением, позволяет осуществлять сквозное подписание и/или шифрование сообщений и гарантирует, что любые проверки целостности (например, хэши или дайджесты ) остаются действительными. Сообщение может быть аннотировано посредниками во время передачи, но любые такие аннотации хранятся отдельно от неизменяемого голого сообщения . Аннотации могут быть добавлены до или после голого сообщения.
Заголовок представляет собой стандартный набор аннотаций, связанных с доставкой, которые могут быть запрошены или указаны для сообщения и включают в себя время жизни, долговечность, приоритет. [22]
Само сообщение структурировано как необязательный список стандартных свойств (идентификатор сообщения, идентификатор пользователя, время создания, ответ, тема, идентификатор корреляции, идентификатор группы и т. д.), необязательный список свойств, специфичных для приложения (т. е. расширенных свойств) и тело, которое AMQP называет данными приложения. [23]
Свойства указаны в системе типов AMQP, как и аннотации. Данные приложения могут быть любой формы и в любой кодировке, которую выберет приложение. Одним из вариантов является использование системы типов AMQP для отправки структурированных, самоописывающих данных.
Протокол связи передает сообщения между двумя узлами , но делает очень мало предположений относительно того, что это за узлы и как они реализованы.
Ключевая категория — это те узлы, которые используются в качестве точки встречи между отправителями и получателями сообщений (например, очереди или темы ). Спецификация AMQP называет такие узлы узлами распределения и кодифицирует некоторые общие поведения. [24]
Это включает в себя:
Хотя AMQP может использоваться в простых одноранговых системах, определение этой структуры для возможностей обмена сообщениями дополнительно обеспечивает взаимодействие с посредниками обмена сообщениями (брокерами, мостами и т. д.) в более крупных, более богатых сетях обмена сообщениями. Указанная структура охватывает базовые поведения, но допускает развитие расширений, которые могут быть далее кодифицированы и стандартизированы.
Версия протокола AMQP 1.0 является текущей версией спецификации. Она фокусируется на основных функциях, которые необходимы для взаимодействия в масштабе Интернета. Она содержит менее явную маршрутизацию, чем предыдущие версии, поскольку основные функции являются первыми, которые были строго стандартизированы. Взаимодействие AMQP 1.0 было более тщательно протестировано с большим количеством реализаторов, чем предыдущие версии. [37]
На сайте AMQP размещена спецификация OASIS для версии 1.0.
Более ранние версии AMQP, опубликованные до выпуска 1.0 (см. Историю выше) и существенно отличающиеся от него, включают в себя:
Эти открытые спецификации протокола охватывают ту же или схожую область, что и AMQP:
Java Message Service (JMS) часто сравнивают с AMQP. Однако JMS — это спецификация API (часть спецификации Java EE ), которая определяет, как реализуются производители и потребители сообщений. JMS не гарантирует взаимодействия между реализациями, и используемая система обмена сообщениями , совместимая с JMS , может потребовать развертывания как на клиенте, так и на сервере. С другой стороны, AMQP — это спецификация протокола на уровне проводов. Теоретически AMQP обеспечивает взаимодействие, поскольку различное программное обеспечение, совместимое с AMQP, может быть развернуто на стороне клиента и сервера.