Реализация proxy-сервера на интеграционной шине

Решение реализовано в одном из довольно крупных банков для кэширования запросов к информационным системам (ИС).

Постановка задачи

В JMS-очереди Tibco Business Works (BW) поступают XML-запросы в каноническом формате:

<request>
    <service>service_name</service>
    <client>client_id</client>
    <requestData>request_data</requestData >
    <replyTo>response_queue</replyTo>
</request>

Здесь:

• service_name – имя сервиса, реализуемого одной из ИС;
• client_id – идентификатор клиента, для которого происходит обращение;
• request_data – тело запроса к сервису;
• response_queue – имя очереди для отправки асинхронного ответа.

BW анализирует service_name и перенаправляет запрос во входящую очередь соответствующего сервиса.

Сервис разбирает запрос, формирует ответ и отправляет его в очередь response_queue. Формат ответа:

<response>
    <service>service_name</service>
    <client>client_id</client>
    <responseData>response_data</responseData >
</response> 

где:

• response_data – тело ответа.

Некоторые сервисы отвечают несколько секунд, а иногда – десятков секунд. Это слишком долго для клиента. При этом иногда запросы повторяются через достаточно короткий промежуток времени, чтобы получать повторяющиеся ответы. В общем, стандартная ситуация для proxy-сервера (proxy).

Предложенное решение

Proxy организуется как отдельный сервис со своей входящей JMS-очередью. Тело запроса к proxy имеет вид:

<request>
    <service>proxy</service>
    <client>client_id</client>
    <requestData>
        service_name
        request_data
        live_time
    </requestData >
    <replyTo>response_queue</replyTo>
</request>

где:
• live_time – время актуальности ответа от сервиса service_name.

Сервис proxy:

• на основании параметров service_name и client_id proxy производит поиск в своем хранилище актуального ответа от сервиса service_name для клиента client_id
• если ответ есть, он отправляется в очередь response_queue как ответ сервиса service_name
• если ответа нет, формируется запрос к сервису service_name

<request>
    <service>service_name</service>
    <client>client_id</client>
    <requestData>request_data</requestData >
    <replyTo>proxy_response_queue</replyTo>
</request>

где proxy_response_queue – JMS-очередь сервиса proxy для ответов ИС; при этом сам запрос сохраняется
• когда в очередь proxy_response_queue приходит ответ ИС, он запоминается в хранилище; затем извлекается сохраненный запрос; на основании запроса и ответа ИС формируется ответ proxy:

<response>
    <service>service_name</service>
    <client>client_id</client>
    <responseData>response_data</responseData >
</response>

и помещается в очередь response_queue.

Это все на сегодня. Если будет интерес, я поясню отдельные моменты подробнее.

Автор: Александр Незнахин

Источник ^[1]