Архитектура CoAP

●похожа на HTTP;

●протоколы без установления соединения;

●безопасность с помощью DTLS, а не TLS, как при нормальной передаче HTTP;

●асинхронный обмен сообщениями;

●легкий дизайн и низкие требования к ресурсам, низкие накладные расходы в плане заголовка;

●поддержка URI и типов содержимого;

●построен на UDP (User Datagram Protocol) вместо TCP (Transmission Control Protocol), как для обычного HTTP-сеанса;

Архитектура CoAP

CoAP имеет два основных уровня:

●уровень запроса/ответа – отвечает за отправку и получение запросов на основе RESTful.

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

Representational State Transfer – Интернет вызов удалённой процедуры

Архитектура CoAP

●оконечные точки – это источники и адресаты сообщения CoAP. Конкретное определение оконечной точки зависит от используемого транспорта;

●прокси – оконечная точка CoAP, которой клиенты CoAP поручают выполнять запросы от своего имени. Снижение нагрузки на сеть, доступ к спящим узлам и обеспечение некоторого уровня безопасности – вот некоторые из функций прокси. В качестве альтернативы прокси может преобразовать один запрос CoAP в другой запрос CoAP или даже перевести на другой протокол (перекрестное проксирование). Общей ситуацией является пограничный маршрутизатор, проксирующий из сети CoAP до сервисов HTTP для облачных интернет-соединений;

Архитектура CoAP

●клиент – инициатор запроса. Оконечная точка назначения ответа;

●сервер – оконечная точка назначения запроса. Создатель ответа;

●посредник – клиент, выступающий в качестве и сервера, и клиента по отношению к исходному серверу. Прокси является посредником;

●сервер происхождения – сервер, на котором находится данный ресурс;

●наблюдатели – клиент наблюдателя может зарегистрировать себя с использованием измененного сообщения GET. Затем наблюдатель подключается к ресурсу, и, если состояние этого ресурса изменяется, сервер отправляет уведомление наблюдателю.

STOMP

STOMP – простой (или потоковый) протокол промежуточного уровня, ориентированный на текстовые сообщения. Брокер, разработанный на одном языке программирования, может получать сообщения от клиента, написанного на другом языке. Протокол похож на HTTP и работает по TCP. STOMP состоит из заголовка кадра и тела кадра. Текущая спецификация – STOMP 1.2 от 22 октября 2012 г., она доступна по бесплатной лицензии. Не касается вопросов подписки или очередей. Брокер должен проанализировать сообщение и сопоставить ему тему или очередь для клиента. Потребитель данных будет подписываться на пункты назначения, предоставленные брокером.

AMQP

AMQP (Advanced Message Queuing Protocol) — открытый протокол для передачи сообщений между компонентами системы. Основная идея состоит в том, что отдельные подсистемы (или независимые приложения) могут обмениваться произвольным образом сообщениями через AMQP-брокер, который осуществляет маршрутизацию, возможно гарантирует доставку, распределение потоков данных, подписку на нужные типы сообщений.

Архитектуру протокола разработал John O’Hara из банка JP Morgan Chase & Co.

А как там дела в промышленности?

Как всегда все плохо… Стандарт OPC-UA

протокол межмашинного взаимодействия для промышленной автоматизации, разработанный Фондом OPC.

●Открытый – свободно доступный и реализуемый под лицензией GPL 2.0

●Кроссплатформенный – не привязана к одной операционной системе или языку программирования

●Сервис-ориентированная архитектура (SOA)

●По факту, просто передача XML по сети с использованием устаревших технологий