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

При разработке приложения разработчик должен знать, куда поместить данные какого типа для совместного использования этих данных с другими приложениями, а также где искать, какие типы данных поступают из других приложений. Эти пути связи не могут быть динамически созданы и обнаружены во время выполнения; их необходимо согласовать во время разработки, чтобы приложение знало, откуда берутся его данные и куда они направляются. Единственным исключением является канал ответа в запросе-ответе. Запрашивающая сторона может создать или получить новый канал, о котором отвечающий ничего не знает, указать его как обратный адрес сообщения запроса, и тогда ответы могут использовать его. Другое исключение - реализации системы обмена сообщениями, поддерживающие иерархические каналы. Получатель может подписаться на родительский в иерархии, затем отправитель может публиковать в новом дочернем канале, о котором получатель ничего не знает, и подписчик по-прежнему будет получать сообщение.
Сначала приложения определяют каналы, по которым система обмена сообщениями будет нужно предоставить. Последующие приложения будут пытаться организовать свое общение по доступным каналам, но когда это нецелесообразно, они потребуют добавления дополнительных каналов. Когда набор приложений уже использует определенный набор каналов, а новые приложения хотят присоединиться к нему, они тоже будут использовать существующий набор каналов. Когда существующие приложения добавляют новые функции, им могут потребоваться новые каналы.
Другой распространенный источник путаницы - это однонаправленный или двунаправленный канал сообщений. Технически это ни то, ни другое; канал больше похож на корзину, в которую одни приложения добавляют данные, а другие берут данные. Но поскольку данные находятся в сообщениях, которые передаются от одного приложения к другому, это дает направление канала, делая его однонаправленным. Если бы канал был двунаправленным, это означало бы, что приложение будет и отправлять сообщения, и получать сообщения из одного и того же канала, потому что приложение будет продолжать использовать свои собственные сообщения, сообщения, которые оно должно отправлять другим приложениям. Таким образом, для всех практических целей каналы однонаправлены. Как следствие, для двустороннего разговора между двумя приложениями им потребуется два канала, по одному в каждом направлении.

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

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

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

Тип данных (Datatype Channel)
Содержимое сообщения должно соответствовать определенному типу, чтобы получатель понимал структуру данных. Тип данных канала - это принцип, согласно которому все данные в канале должны быть одного типа. Это основная причина, по которой системам обмена сообщениями нужно много каналов; если бы данные могли быть любого типа, системе обмена сообщениями потребовался бы только один канал (в каждом направлении) между любыми двумя приложениями.

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

Защита от сбоев
Если система обмена сообщениями дает сбой или отключается на техническое обслуживание. Когда он будет снова запущен и запущен, эти сообщения все еще будут в его каналах. По умолчанию нет; каналы хранят свои сообщения в памяти. Однако Гарантированная доставка делает каналы постоянными, так что их сообщения хранятся на диске. Это снижает производительность, но делает обмен сообщениями более надежным.

Клиенты без обмена сообщениями
Если приложение не может подключиться к системе обмена сообщениями, но все же хочет участвовать в обмене сообщениями. Но если система обмена сообщениями может каким-либо образом подключаться к приложению - через свой пользовательский интерфейс, API бизнес-сервисов, свою базу данных или через сетевое соединение, такое как TCP / IP или HTTP, - тогда адаптер канала на систему обмена сообщениями можно использовать для подключения канала (или набора каналов) к приложению без необходимости изменять приложение и, возможно, без необходимости иметь клиент обмена сообщениями, работающий на том же компьютере, что и приложение.

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

Первоначально опубликовано на madhukaudantha.blogspot.com.