Объект глобального ресурса весной

Question

Я просто попадаю в Spring (и Java), и, несмотря на довольно много исследований, я не могу даже выразить терминологию для того, что я пытаюсь сделать. Я просто объясню задачу, и, надеюсь, кто-то может указать мне на правильные весенние сроки.

Я пишу приложение Spring-WS, которое будет действовать как промежуточное ПО между двумя API. Он получает запрос SOAP, выполняет некоторую бизнес-логику, обращается к внешнему XML-API и возвращает ответ SOAP. Однако внешний API является странным. Я должен выполнить «обнаружение службы» (сделать некоторые вызовы API для определения допустимых конечных точек - параметр в XML-запросе) в различных ситуациях (больше, чем через X часов после последнего запроса, больше, чем Y запросов с момента последнего обнаружения и т. Д. .).

Моя мысль заключалась в том, что я мог бы иметь класс/bean/whatever (не уверен в лучшей терминологии), которые могли бы обрабатывать все это свойство обнаружения службы в фоновом режиме. Затем обработчики запросов могут запрашивать эту «вещь», чтобы получить действительную конечную точку без необходимости выполнять собственное обнаружение и замедлять обработку запроса. (Обнаружение сервисов нужно повторно выполнять редко, поэтому было бы полезно сделать это для каждого запроса.)

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

Как я могу создать экземпляр «нечто», что может:

1) просыпаются в определенный интервал и запустить метод (т.е. проверить, если необходимо выполнить после X часов, и если да Обнаружение служб сделай это).

2) Предоставьте что-то вроде метода геттера, который может возвращать некоторые строки.

3) Обеспечьте способ в # 2 выполнить метод в фоновом режиме без задержки return (в основном обнаружить, что свойство экземпляра превышает значение и выполнить - или я полагаю, выдаю запрос на выполнение - метод экземпляра).

У меня есть опыт работы с многопоточным программированием, и у меня нет проблем с использованием потоков и мьютексов. Я просто не уверен, что это правильный путь весной.

Answer 1

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

• Создать неизменяемый (стоимость) объект MyEndpointDiscoveryResults для хранения результатов обнаружения (например, адрес конечной точки (а) или любой другая информация имеет отношение к потребителям SOAP).
• Создать одноэлементную фасоль Весна фасоль MyEndpointDiscoveryService.
• В службе обнаружения сохраните AtomicReference<MyEndpointDiscoveryResults> (или даже просто переменную переменную). Это гарантирует, что все потоки будут видеть обновленные результаты, а ограничение их до одного, атомически обновляемого поля, содержащего неизменяемый объект, ограничивает объем взаимодействий параллелизма.
• Используйте @Scheduled или другой механизм для запуска соответствующего протокола обнаружения. Когда есть обновление, создайте весь объект результата, а затем сохраните его в обновленном поле.