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

в 10:44, , рубрики: tibco systems; integration; esb, Анализ и проектирование систем, Разработка систем передачи данных, системное программирование

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

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

В 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.

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

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

Источник

Поделиться

* - обязательные к заполнению поля