В STOMP адрес назначения (destination) представляет собой строковый идентификатор канала доставки сообщений между клиентом и брокером. Он не является объектом или структурой данных, а строго интерпретируется серверной частью маршрутизации сообщений. Формат строки определяется соглашениями конкретного брокера, но в большинстве реализаций сохраняется общая логика: адрес описывает логический путь доставки сообщения к подписчикам или обработчикам.
Ключевая особенность заключается в том, что STOMP не навязывает единый стандарт структуры адресов, оставляя это на уровень брокера сообщений. В результате одинаковые STOMP-клиенты могут работать с различными схемами маршрутизации без изменений в коде, но с различными правилами формирования destination.
Адрес назначения почти всегда строится как иерархический путь,
похожий на файловую систему. Используются разделители, чаще всего символ
/, формируя логические категории.
Типичная форма:
/segment/subsegment/identifierТакая структура применяется для упрощения группировки сообщений и фильтрации подписок.
Примеры:
/topic/chat/general
/queue/orders.processing
/app/events/user.createdКаждый сегмент несет смысловую нагрузку:
В большинстве брокеров STOMP различает два фундаментальных паттерна доставки сообщений.
Адреса типа topic используются для широковещательной модели, где одно сообщение получают все подписчики.
Пример:
/topic/news
/topic/notifications.systemОсобенности:
Адреса queue реализуют модель индивидуальной доставки, где сообщение получает один потребитель.
Пример:
/queue/tasks
/queue/payments.processОсобенности:
В STOMP существует механизм пользовательских destinations, позволяющий доставлять сообщения конкретному клиенту.
Часто используется префикс:
/user/queue/...Примеры:
/user/queue/notifications
/user/queue/private.messagesТакие адреса не привязаны к глобальной очереди или топику. Брокер выполняет дополнительное сопоставление на основе сессии, идентификатора пользователя или токена авторизации.
В серверных реализациях (например, Spring-based брокерах) пользовательский destination преобразуется в внутренний уникальный канал, связанный с конкретным соединением.
Во многих архитектурах STOMP используется разделение пространства имён на уровне префиксов.
Наиболее распространённая схема:
/app — сообщения, отправляемые в серверную логику
(application destination)/topic — публикация событий/queue — очереди задач/user — персональные каналыПример маршрутизации:
/app/order.create → обработка на сервере
/topic/order.events → рассылка всем клиентам
/queue/order.jobs → очередь обработкиТакое разделение позволяет разграничить входящие команды и исходящие события, снижая вероятность конфликтов в маршрутизации.
Хотя STOMP не накладывает строгих ограничений на формат строки, на практике применяются следующие правила:
/Некоторые брокеры дополнительно поддерживают:
* как wildcard для одного сегмента** для множественных сегментов{variable}Пример шаблонов:
/topic/chat.*
/queue/orders.**
/topic/user.{id}.eventsОднако поддержка таких выражений не является частью STOMP-спецификации и определяется конкретной реализацией.
В STOMP.js destination передаётся как строка при подписке:
client.subscribe("/topic/chat/general", (message) => {
console.log(message.body);
});И при отправке:
client.publish({
destination: "/app/message.send",
body: JSON.stringify({ text: "hello" })
});Важно, что клиент не интерпретирует структуру destination — он лишь передаёт строку брокеру. Вся логика маршрутизации происходит на серверной стороне.
В сложных системах destination становится частью глобальной схемы маршрутизации. Для предотвращения конфликтов используется доменное именование:
/topic/{domain}/{service}/{event}
/queue/{service}/{task}
/app/{module}/{command}Пример:
/topic/billing/invoices.created
/queue/auth/password.reset
/app/user/profile.updateТакой подход обеспечивает:
Разные брокеры по-разному трактуют одинаковые destination:
Из-за этого одна и та же строка:
/topic/chat.generalможет соответствовать разным внутренним механизмам доставки.
Некорректная структура destination часто приводит к проблемам масштабирования и поддержки системы.
Типичные ошибки:
Использование плоской структуры без иерархии:
/chat1
/chat2
/chat3Смешивание типов сообщений в одном пространстве:
/dataОтсутствие разделения команд и событий:
/messagesПерегруженные длинные пути без семантики:
/app/v1/user/profile/settings/update/request/confirmedТакие подходы затрудняют маршрутизацию, фильтрацию и сопровождение системы.
Destination выступает связующим слоем между клиентской логикой и брокером сообщений. Он определяет не только маршрут доставки, но и архитектурную структуру всей системы обмена сообщениями. Через корректно спроектированные адреса формируется модель взаимодействия между сервисами, пользователями и событиями, где каждая строка становится частью общей схемы распределённой коммуникации.