Реализация. Создание корпоративной сервисной шины

9.3 Проектирование компонентов

При проектировании компонентов для proxyAssessorSystem следует принимать во внимание несколько составляющих окончательной реализации:

1. Наборы сообщений, соответствующие интерфейсам решения.
2. Потоки сообщений и независимость от транспортного протокола.
3. Таблицы баз данных.
4. Распределение и агрегация.

В этом разделе описывается высокоуровневый дизайн и проблемы при реализации этих четырех областей.

• 9.4 "Реализация наборов сообщений"
• 9.5, "Реализация таблиц баз данных"
• 9.6, "Создание потоков сообщений"
• 9.7, "Создание кода ESQL для потоков сообщений"

9.3.1 Наборы сообщений

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

Выбор обработчика

В WebSphere Business Integration Message Broker доступ к содержимому сообщений в протоколе SOAP предоставляет XML-обработчик или MRM-обработчик. XML-обработчик достаточно эффективен, но не имеет возможности проверять сообщения и не требует предоставления определения сообщения. Это может рассматриваться и как преимущество и как недостаток. Обработчик интерпретирует SOAP-сообщение в работающей системе, используя XML-теги в этом сообщении. MRM-обработчик, напротив, может проверять сообщения по их определениям, требует предоставления определения, а в ходе создания потока сообщений может помочь в анализе содержимого сообщений при выполнении SQL-инструкций, которые запрашивают и записывают сообщения.

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

Создание определений сообщений для SOAP-интерфейсов

WebSphere Business Integration Message Broker импортирует файлы схем, но он не имеет средств импорта WSDL. Чтобы создать определения сообщений по WSDL-файлам, нам нужно извлечь определения схем из высокоуровневых элементов сообщений, содержащихся в WSDL-файле, предоставленном архитектором решения, и импортировать эти определения в набор сообщений WebSphere Business Integration Message Broker. Каждому интерфейсу (и запрос и запрос/ответ рассматриваются как один интерфейс) соответствует свое определение в одном и том же наборе сообщений. Далее, импортируя схему, созданную по определению SOAP 1.1 WSDL, и объединяя эту SOAP-схему со схемой каждого интерфейса, мы создаем определения сообщений для каждого интерфейса.

Все необходимые файлы схем мы уже создали из соответствующих WSDL-файлов и сохранили в директории дополнительных материалов .\SG24-6636\Broker\Schemas. Процедура преобразования WSDL в схему описывается в следующих разделах.

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

Реализация всех определений интерфейсов описывается в разделе 9.4, "Реализация наборов сообщений".

9.3.2 Потоки сообщений и независимость от транспортного протокола

На схеме последовательностей ( рис. 9.3) показаны все взаимодействия системы proxyAssessorSystem. В качестве примера на рис. 9.9 более подробно показаны потоки 3, 3a, 4 и 4a.

увеличить изображение
Рис. 9.9. Потоки 3, 3a, 4 и 4a

Каким образом следует устанавливать соответствия между интерфейсами, показанными на рис. 9.9, и потоками сообщений в брокере?

• Будет как минимум один поток для каждой службы, предлагаемой брокером (в табл. 9.1 они показаны как пять выделенных жирным шрифтом записей). Мы называем их сервисными потоками (Service Flows), поскольку они являются реализациями Web-служб. Два из них показаны на рис. 9.9.
• Существует пять потоков, которые вызывают выходные интерфейсы. Они называются клиентскими потоками (Client Flows), поскольку они являются клиентами Web-служб, предоставляемых другими серверами.
• Для поддержки тех взаимодействий, которые в LGI переводятся с SOAP/Http на SOAP/JMS, входные и выходные узлы LGI разделены и упакованы в специальный, специфический для транспортного протокола, проект набора сообщений.
• Существуют потоки Fault (Ошибка) и Reply (Ответ), которые являются общими для всех сервисных потоков в решении, и они реализованы в виде специфичных для транспортного протокола потоков. Они возвращают ответы или ошибки клиентам служб, реализуемых брокером.
• Клиентские потоки должны перехватывать любые ошибки, возникающие в потоках, или возвращаемые службами, которые они вызывают.

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

Обработчик ошибок в клиентских потоках реализован в виде узла TryCatch, соединенного с входным узлом подпотока. Ошибки передаются в отдельный обработчик ошибок, который мы назвали потоком клиентской ошибки (ClientError).

• В данном проекте все взаимодействия с оценщиками ограничиваются протоколом SOAP/http и обрабатываются как часть главного потока.

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

• Помимо этих типов потоков, для входящих подтверждений, относящихся к запросам, посланным через MQ или JMS-систему, есть отдельные потоки Ack, поскольку не существует комбинированного узла "запрос/ответ". Ответ должен передаваться в отдельном потоке. Нам не нужны эти дополнительные потоки при использовании SOAP/Http, поскольку для SOAP/Http существует синхронный узел HttpRequest. Следовательно, Ack-потоков для SOAP/Http не существует, и нам не нужно создавать такие потоки для нашего решения.

Различные типы потоков и их взаимоотношения показаны на рис. 9.10.

Рис. 9.10. Разделение общих потоков и потоков, специфичных для транспортного протокола

Преимущества упаковки транспортно-специфических потоков LGI (верхний ряд синих прямоугольников) отдельно от общих потоков и потоков оценщика (оранжевый нижний ряд прямоугольников) состоит в том, что при переводе шины LGI с SOAP/Http на SOAP/JMS необходимо изменить только потоки, обозначенные синим цветом.

С помощью небольшого художественного надругательства над исходными UML-схемами последовательностей ( рис. 9.11) мы показали соответствия потоков AssessorAvailability части схемы последовательности из Rational Software Architect с целью графически продемонстрировать корреляцию между потоками, которые мы разработали для брокера, и взаимодействиями, указанными в архитектуре решения.

увеличить изображение
Рис. 9.11. Потоки в AssessorAvailability

На рис. 9.12 показано эквивалентное представление потоков Assessor Report.

увеличить изображение
Рис. 9.12. Потоки в Assessor Report

Краткие описания потоков

В табл. 9.2 показаны общие потоки, а в табл. 9.3 – потоки, независимые от транспортных протоколов, некоторые из которых также взаимодействуют с оценщиками, а в табл. 9.4 показаны потоки, взаимодействующие с LGI.

9.3.3 Таблицы баз данных

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

CLAIMASSESSOR

Таблица CLAIMASSESSOR используется для хранения сведений о запросах готовности, направляемых оценщикам (поток4), и в нее заносится информация об ответах оценщика на эти запросы.

ACTIONASSESSOR

Таблица ACTIONASSESSOR используется для хранения информации о запросах подтверждения, направляемых оценщикам (поток7), и в нее заносится информация от ответах оценщика на эти запросы.

RESOLVEASSESSOR

Таблица RESOLVEASSESSOR используется, если существует несколько типов оценщиков с разными форматами сообщения, и нам нужно определить, оценщику какого типа посылается конкретное сообщение. Данная таблица связывает тип с каждым идентификатором оценщика, а также предоставляет технические данные, например HTTP-адрес. В данной реализации доступ ко всем оценщикам осуществляется по протоколу SOAP/http, и мы эту таблицу не используем.

9.3.4 Распределение и агрегация

Важной возможностью, которую предоставляет брокер, является распределение и агрегация сообщений. В системе proxyAssessorSystem данная возможность используется для отправки подходящим внешним оценщикам запросов на выдвижение предложений по проведению оценки претензии, а затем для объединения получаемых ответов. Процесс ExternalClaimAssessor посылает список подходящих оценщиков в систему proxyAssessorSystem. Система proxyAssessorSystem разделяет список на отдельные запросы (которые в полной реализации будут отправляться с использованием разных транспортных протоколов) и отправляет их через SOAP/Http, получая подтверждения от каждого оценщика, получившего запрос. В течение какого-то времени, которое определяется контрактом между LGI и оценщиками и которое может зависеть от вида страховки клиента, все оценщики могут присылать предложения. Предложения объединяются (агрегируются) системой proxyAssessorSystem и посылаются процессу ExternalClaimAssessor в виде единого списка.

Узлы агрегации

Брокер предлагает три узла для реализации агрегации:

1. Узел Aggregate Control.
2. Узел Aggregate Request.
3. Узел Aggregate Reply.

Узлы Aggregate Control и Aggregate Request используются в потоке распределения, а узел Aggregate Reply – в потоке агрегации для сбора ответов. Узлы агрегации формируют основу для реализации распределения и агрегации. ИТ-специалист по брокеру должен связать поток сообщений с этими узлами и обработать создание разветвляющихся сообщений и сборного сообщения. Прежде чем обращаться к проектированию системы proxyAssessorSystem, следует принять во внимание несколько вопросов, связанных с проектированием.

Один поток или два?

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

Транспортные протоколы

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

• WebSphere MQ Enterprise Transport (узлы MQInput и MQOutput);
• WebSphere MQ Mobile Transport (узлы MQeInput и MQeOutput).

Брокер не поддерживает встроенные протоколы, которые не соответствуют модели запрос/ответ или пользовательские транспортные протоколы:

• WebSphere MQ Web services Transport (узлы HTTPInput, HTTPReply и HTTPRequest);
• WebSphere MQ Real-time Transport (узлы Real-timeInput и Real-timeOptimizedFlow);
• WebSphere MQ Telemetry Transport (узлы SCADAInput и SCADAOutput).

Нам нужно, чтобы служба агрегации поддерживала любой тип транспортного протокола, поскольку мы разрешаем оценщикам связываться с LGI, используя разные протоколы. Решением является преобразование в брокере потоков, связанных с определением готовности оценщиков, для использования WebSphere MQ и преобразование запросов, направляемых к оценщикам и от них, между протоколами WebSphere MQ и HTTP/SOAP. В документах центра информации версии 5 описываются интерфейсы узлов агрегации, позволяющие создавать агрегационные потоки, не относящиеся к WebSphere MQ. Реализация такого интерфейса имеется в WebSphere Business Integration Message Broker Version 6.0, и в нее входит поддержка агрегации для протокола SOAP/http, что устраняет необходимость использовать промежуточные потоки WebSphere MQ.

Надежность и тайм-ауты

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

Тайм-ауты

Истечение времени ожидания (тайм-аут) следует рассматривать как часть требований, предъявляемых к процессу, и его должны задавать бизнес-аналитик и архитектор. В нашем случае значения тайм-аута включаются в контракты с клиентами и оценщиками. Нужно установить два вида тайм-аутов. На рис. 9.13 зелеными кружками обозначены узлы, для которых нужно установить тайм-ауты.

увеличить изображение
Рис. 9.13. Полное представление распределения и агрегации сообщений

Первый тайм-аут относится к узлу Aggregate Control. Он управляет общей продолжительностью процесса агрегации: сколько времени процесс будет ждать ответа от оценщиков. Значение, указанное в контракте между LGI и оценщиками, должно удовлетворять времени ответа, которое ожидает от LGI клиент, которому был продан страховой полис. Как только срок тайм-аута превышен, узел Aggregation Reply начинает направлять ответы на другой выходной терминал – для обработки опоздавших ответов.

В случае процесса обработки претензии существует два класса клиентов с разными ожидаемыми временами ответов, для которых, следовательно, необходимо определить два разных параметра тайм-аута. Поскольку значение тайм-аута жестко прописано в свойстве узла Aggregate Control, для двух разных типов клиентских контрактов нужно создать два узла Aggregate Control. В нашей реализации, для упрощения, поддерживается только один полис с прописанным временем ответа.

Второе значение таймаута, которое устанавливается для узла Aggregation Reply, выбрать сложно, но оно не является очень критических. В нем указывается, как долго узел Aggregation Reply будет ждать получения сообщения, прежде чем будет принято решение о невозможности связать его с управляющим сообщением, посланным из узла Aggregation Control. После истечения срока тайм-аута узел Aggregation Reply отправляет сообщение на свой терминал Unknown. Это глобальное свойство узла Aggregation Reply.

В качестве иллюстрации представьте себе такую ситуацию: вы планируете сесть на поезд, идущий в Лондон на безлюдной станции. Вы знаете, что поезда на Лондон ходят довольно точно по расписанию, и вы хотите сесть на поезд в 10:00. Если вы попадете на станцию в 10:01 и поезда на станции не окажется, будет ли это означать, что вы пропустили поезд или что поезд опаздывает? Сколько вы будете ожидать на станции, прежде чем решите, что вы пропустили поезд? В данном примере поезд – это управляющее сообщение время, которое он проводит у платформы, – общая продолжительность агрегации, а пассажиры, желающие попасть на поезд, – это агрегируемые ответы. Второе значение тайм-аута – это время ожидания, прежде чем будет принято решение о том, что поезд ушел или вообще не придет.

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

Прерывания

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

Проектирование потоков распределения и агрегации

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

Поток 4

Запрос о готовности, полученный от процесса ExternalClaimAssessor, был принят и проверен. Поток 4 вызывается из потока 3.

Подготовка

1. Сообщение HTTP/SOAP принимается из входного серверного потока (Input) после проверки.

2. Узел TryCatch определяет контекст ошибки для оставшейся части обработки, выступая в роли SOAP-клиента при запрашивании информации о готовности у всех оценщиков.

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

4. Узел Prepare MQ удаляет все следы HTTP-запроса из папок брокера^{3Мы обнаружили, что некоторые функции брокера могут быть введены в заблуждение, если в брокере одновременно присутствуют папки MQ и http. Поэтому важно при переключении транспортных протоколов очищать старые ненужные папки.} и задает папку MQ для создания нового MQ-сообщения.

Aggregate Control

5. Узел Aggregate Control (AC) запускает процесс распределения/агрегации:

• Как уже говорилось ранее, в узле АС указывается тайм-аут ответов.
• Также агрегату присваивается имя, чтобы отличить его среди других агрегатов, которые могут формироваться. Например, мы реализовали разные агрегаты с разными временами ответа.
• Узел АС помещает информацию в папку LocalEnvironment, которая должна быть связана с узлом Aggregate Request и узлом MQ Output, которые будут посылать управляющее сообщение на узел Aggregate Reply.
• Узел PrepareMQControl создает управляющее сообщение, которое посылается по MQ к Flow4.(MQMD). В примере 9.1 показано, как можно создать новый MQMD.

CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN 'MQMD';
SET OutputRoot.MQMD.StrucId = MQMD_STRUC_ID;
SET OutputRoot.MQMD.Version = MQMD_CURRENT_VERSION

Fan-Out

6. Узел Fan-Out распространяет отдельные сообщения-запросы последовательно по оставшейся части потока, перебирая элементы списка подходящих оценщиков в запросе. Каждое сообщение-запрос направляется новому оценщику, в новую точку назначения. В примере 9.2 показано, как можно задать URL оценщика.

OutputLocalEnvironment.Destination.HTTP.RequestURL =
InputRoot.MRM.soap11:Body.fl3:requestAssessorAvailability.fl3:assessorL
ist.fl3:assessors[assessorCount].fl3:assessorURL;

В параметрах вычислительного узла Fan Out должно быть указано распространение папки LocalEnvironment, а также обычный параметр распространения дерева сообщений. Также должна быть строчка кода (пример 9.3), копирующая папку LocalEnvironment, которая была получена от узла Aggregate Control.

-- Для узла агрегации необходима следующая инструкция
SET OutputLocalEnvironment = InputLocalEnvironment;

MQOut Assessor

7. Узел MQOut Assessor, по сути, посылает сообщение WebSphere MQ в очередь оценщика. Сообщение никуда не посылается, но в папке LocalEnvironment создается папка Written Destination, которая используется узлом Aggregate Request для задания корреляционной информации для агрегации.

Мы извлекли сгенерированный идентификатор сообщения (MsgID) из папки Written Destination, чтобы убедиться в том, что он идентичен тому, который был сохранен узлом Aggregation Request. У нас были определенные проблемы при сохранении нашего собственного MsgID в MQMD и при включении опции узла MQOut, запрещающей генерацию нового MsgID. Казалось, что он не совпадает с тем, который указан в таблице узла Aggregation Request. Чтобы быть уверенными в том, что скрытый MsgId, сохраненный узлом Aggregation Request, идентичен тому, который мы сохранили в таблице CLAIMSASSESSOR, мы сохранили MsgID из папки Written Destination. Таким образом, мы можем быть абсолютно уверены в том, что мы сохраняем тот же MsgID, что и в узле Aggregation Request. Мы так и не смогли выяснить, почему ошибки были связаны с MsgID, но формирование потока с использованием папки Written Destination устранило возможность возникновения проблемы.

AggregateRequest

8. Все, что мы предоставили для узла Aggregate Request – это имя папки, которая долж- на быть создана для хранения объединенного сообщения-ответа (пример 9.4).

InputRoot.comIbmAggregateReply.<имя папки>

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

Save AssessorRequest

9. Узел Save AssessorRequest сохраняет MsgId (= ReplyIdentifier) в папке WrittenDestination, в базе данных ClaimsAssessor, в форме поля CorrelId, с указанием для него значений ClaimID и AssessorID. Это значение для каждого ответа восстанавливается в поле MQMD.CorrelId, когда ответ попадает в поток 3а (пример 9.5).

INSERT INTO Database.EMERGE.CLAIMASSESSOR (
  claimID, assessorID, assessorURL,location, reqdate, makeofcar,
  registration,replytoq, replytoqmgr, correlid) VALUES (
  InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
claimID,
  InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:
assessorID,
  InputLocalEnvironment.Destination.HTTP.RequestURL,
  InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:location,
  InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:reqDate,
  InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:cardet.
    fl7:makeOfCar,
  InputRoot.MRM.soap11:Body.fl7:requestAssessorAvailability.fl7:cardet.
  fl7:registration,
    'NoReplytoQ',
  'NoReplytoQmgr',
  InputLocalEnvironment.WrittenDestination.MQ.DestinationData.msgId);

SOAP/HTTP Assessor

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

Поток 3а

Поток 3а получает управление от потока 4а, который реализует для оценщиков службу возврата данных о готовности.

Подготовка

1. Узел TryCatch определяет контекст обработки исключений для оставшейся части процесса, который является клиентом процесса ExternalClaimsAssessor.

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

3. Узел Prepare Reply очищает всю информацию HTTP/SOAP из папок брокера и фактически создает сообщение-запрос, включив в нее всю информацию ответа оценщика для передачи ее в узел MQReply. Делается это для того, чтобы казалось, будто бы все время велась обработка сообщения MQ Request, без передачи его через HTTP.

4. Узел MQReply AggIn помещает ответ в очередь AggIn reply и использует значение опции MQMD для копирования MsgID (который сейчас представляет собой исходное значение ReplyIdentifier) в поле CorrelId.

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

MQInput AggIn

5. Узел MQInput AggIn получает сообщение-ответ из очереди AggIn и передает его узлу AggregateReply.

MQInput Control

6. Узел MQInput Control получает управляющее сообщение на FLOW3A.CONTROLQ и передает его в узел AggregateReply.

Aggregate Reply

7. Узел Aggregate Reply формирует объединенное сообщение-ответ в папке, указанной узлом Aggregate Request. Как уже обсуждалось ранее, работает два таймера. Таймер Unknown направляет опоздавшие ответы на терминал нераспознанных сообщений. Таймер Timeout отправляет неготовое объединенное сообщение на терминал Timeout. На схеме оба таймера направляют сообщения к узлам трассировки. На практике нам нужно создать сообщение-запрос, идущее к процессу ExternalClaimAssessors либо от выходного терминала, либо от терминала Timeout.

Generate Output3a

Узел Generate Output3a конструирует сообщение-запрос, используя папку объединенного запроса, созданную узлом AggregateReply.