Транслятор сообщений (Message Translator)

Маршрутизатор сообщений (Message Router)

Механизмы интеграции сообщениями

В ситуациях, когда выходной результат одного фильтра должен быть передан на вход одного из нескольких возможных фильтров в зависимости от какого-либо условия (например от содержания результата или от текущей обстановки), целесообразно применять шаблон Маршрутизатор сообщений. В терминах архитектурного стиля типа Pipes and Filters, Message Router является частным случаем фильтра, принимающего сообщения с одного или нескольких входов и пересылающего эти сообщения не внося никаких изменений в один или несколько каналов в зависимости от заданных условий.

Мершрутизатор сообщений является полным аналогом сетевого маршрутизатора в IP сетях, который так же выполняет пересылку пакетов не изменяя их содержимое.

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

Одной из основных концепций преследуемых при интеграции корпоративных приложений является концепция слабой связанности (low coupling). Это обусловлено тем, что приложения входящие в состав корпоративной инфраструктуры часто заменяются на более новые версии или вообще другие приложения. Таким образом, при условии сильной связанности приложений друг с другом, возникают большие сложности при независимом их развитии. Кроме того, при выполнении проектов по интеграции, часто возникает необходимость организовать обмен данными между разнородными приложениями. Формат данных в таких приложениях может сильно различаться, что приводит к необходимости выработки решений позволяющих таки обмениваться данными между приложениями. Такими решениями могут являться:

• Приведение всех приложений к работе в едином формате данных – данный подход, как правило, является невозможным, так как при проведении интеграции разнородных приложений, часто оказывается экономически не оправданным вносить какие либо изменения в уже существующие приложения. Либо такие изменения вообще не могут быть внесены (например, в случае с коробочными приложениями, у которых отсутствует исходный код).
• Выработка единого формата данных и преобразование на входе и выходе каждого приложения (на End Point’ах) данных из внутреннего формата к общему формату – при этом подходе так же требуется модификация (хотя и меньшая) приложений, что не всегда является возможным или экономически оправданным. Кроме того встаёт задача о выработке единого формата данных, которая сама по себе является далеко не тривиальной, так как такой формат должен удовлетворять как все существующие приложения, так и предусматривать развитие корпоративной среды. В промышленности существует ряд стандартов, направленных на создание единого формата обмена данными, к ним относятся, например, ebXML, EDI (Electronic Data Exchange) и другие.
• Использование подключаемых трансляторов сообщений, которые встраиваются в инфраструктуру обмена сообщениями и прозрачно преобразуют сообщения из одного формата в другой (например, из файла разделённого запятыми (coma separated file) и передаваемого по разделяемой файловой системе (отшареному диску) (shared file) в сообщение в формате основанном на XML передаваемому по протоколу HTTP) – такой подход оказывается наиболее гибким, так как позволяет проводить эволюционное преобразование форматов данных (отсутствует необходимость резкой смены формата данных для всех приложений) без необходимости модифицировать существующие приложения.

Дата добавления: 2014-01-05