Inf_comp_sys

Самый простой путь – сделать так, чтобы все сообщения в одном канале принадлежали одному типу, если же сообщения должны отличаться, то снабдить их надежным идентификатором, т.е. флагом, по которому можно будет их отличить (Диаграмма 15).

Прайс-лист Канал прайс-листов

Диаграмма 15

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

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

16.3.5 Канал недопустимых сообщений

При получении сообщения получатель должен уметь интерпретировать его данные и понимать их значение. Но это не всегда возможно, так как в сообщении могут содержаться ошибки как синтаксические, так и лексические. Отправитель по ошибке может поместить сообщение в канале с несоответствующим типом данных. В таком случае получатель не сможет корректно обработать сообщение, и поэтому сообщение будет принято как недопустимое (Диаграмма 16).

131

Но если она выходит из строя, то сообщения, хранившиеся в памяти, будут потеряны. Чтобы предотвратить эту проблему, необходимо использовать гарантированную доставку, записывающую сообщения на диск (Диаграмма 18).

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

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

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

Гарантированную доставку следует отключать во время тестирования и отладки. Тогда для полной очистки всех каналов сообщений потребуется перезапуск системы обмена сообщениями.

16.3.8 Адаптер канала

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

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

134

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

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

Для того чтобы подключить такое приложение к системе обмена сообщениями необходимо использовать адаптер канала, который сможет осуществить доступ к интерфейсу или данным изолированного приложения, создать на основе этих данных сообщение и разместить его в канале. Аналогичным образом адаптер канала может получать сообщения, а затем в зависимости от их содержимого вызывать в приложении ту или иную функциональность (Диаграмма 19).

Приложение

Диаграмма 19

Адаптер канала выполняет роль клиента для системы обмена сообщениями и по ее требованию вызывает функции приложения через его интерфейс. Также он может отслеживать события, происходящие внутри приложения, и в ответ на них использовать систему обмена сообщениями. Благодаря такой схеме каждое приложение может взаимодействовать с системой обмена сообщениями, а следовательно, и интегрироваться с другими приложениями.

Адаптер канала может подключаться к различным уровням архитектуры приложения (Диаграмма 20). В зависимости от особенностей архитектуры и того, какие данные нужны системе обмена сообщениями, выделяют несколько типов адаптеров.

135

Интерфейс

пользователя

Бизнес

логика

Адаптер

База канала данных

Диаграмма 20

Адаптер интерфейса пользователя. Адаптеры такого типа эффективны во многих ситуациях. Например, приложение реализовано на платформе, которая не поддерживается системой обмена сообщениями. Это исключает возможность функционирования адаптера канала на платформе приложения. Однако, пользовательский интерфейс таких приложений обычно доступен с других компьютеров и платформ. Кроме того, популярность архитектуры тонких клиентов на основе Web привела к возрождению интеграции через интерфейс пользователя. Применение пользовательских интерфейсов, основанных на HTML, значительно облегчает создание HTTP-запроса и обработку результатов. Еще одним преимуществом интеграции на основе пользовательского интерфейса является отсутствие необходимости доступа к внутренним механизмам приложения. Иногда предоставление доступа к внутренним функциям системы невозможно или нежелательно. Используя адаптер интерфейса пользователя, другие системы получат такой же доступ к приложению, как и обычный пользователь. Недостаткам таких адаптеров является потенциальная уязвимость и низкая скорость обмена данными. Приложение должно обрабатывать данные, введенные пользователем, и визуализировать на экране соответствующее окно. Адаптер канала, в свою очередь, должен преобразовывать содержимое этого окна обратно в необработанные данные. Этот процесс включает в себя много лишних шагов и выполняется довольно медленно, кроме этого пользовательские интерфейсы меняются гораздо чаще, чем логика приложения, а каждое изменение интерфейса пользователя влечет за собой необходимость соответствующего изменения адаптера канала.

Адаптер бизнес-логики. Большинство бизнес-приложений предоставляют доступ к своей функциональности посредством интерфейсов API. Это может быть как набор компонентов, так и прямой программный интерфейс. Данные

136

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

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

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

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

Некоторые адаптеры канала являются однонаправленными. К примеру, если адаптер канала подключается к приложению через протокол HTTP, он сможет только потреблять сообщения и в ответ на них вызывать функции приложения.

Существует другая разновидность адаптера канала – адаптер метаданных или адаптер времени разработки. Данные адаптеры не вызывают функций приложения, а извлекают метаданные, описывающие внутренние форматы данных приложения. Извлеченные метаданные могут затем быть использованы для настройки трансляторов сообщений или для обнаружения изменений в форматах данных, используемых приложением.

137

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

16.3.9 Мост обмена сообщениями

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

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

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

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

Диаграмма 21

Если рассматривать систему обмена сообщениями как единый, цельных объект, то связать между собой две такие системы не представляется

138

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

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

16.4Построение сообщений

При создании и отправке сообщений возникает несколько вопросов.

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

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

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

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

139

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

16.4.1 Сообщение с командой

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

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

Существует известный шаблон для инкапсуляции запроса в объект. Шаблон команда показывает, как превратить запрос в объект, который можно хранить или передавать дальше. Если бы этот объект будет сообщением, то его можно будет передать по каналу сообщений. Аналогичным образом состояние команды можно будет сохранить внутри состояния сообщения.

Для надежного вызова процедуры необходимо использовать сообщение с командой для надежного вызова процедуры другого приложения (Диаграмма

22).

C - команда

Диаграмма 22

Сообщение с командой - это обычное сообщение, в котором содержится команда. Сообщение с командой обычно отправляется по каналу точка-точка, чтобы каждая команда была потреблена и выполнена только один раз.

16.4.2 Сообщение с данными документа

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

140