Длительная архитектура веб-сервиса

Question

Мы используем axis2 для создания наших веб-сервисов и сервер Jboss для запуска логики всех наших приложений. Нас попросили создать веб-сервис, который общается с bean-компонентом, на ответ на который может потребоваться до 1 часа (в зависимости от размера запроса), поэтому мы не сможем поддерживать соединение с потребителями, открытым в течение этого времени.

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

У меня есть следующие вопросы:

1. Как запросить состояние компонента на сервере Jboss после того, как я вернулся из метода в службе, создавшей этот компонент. Нужно ли использовать бобы с состоянием?
2. Могу ли я использовать бины с отслеживанием состояния, если я хочу выполнять асинхронные вызовы со стороны веб-службы?

Answer 1

Другой подход, который вы можете использовать, - это использование JMS и БД.

Процесс будет

1. При вызове веб-службы поместите сообщение в очередь JMS
2. Вставить запись в таблицу БД и вернуть клиенту уникальный идентификатор для этой записи
3. В MDB, который слушает очередь, вызовите компонент
4. Когда компонент возвращается, обновите запись в БД со статусом «Готово»
5. Когда клиент вызывает состояние, прочитайте запись в БД, верните «Not Done» или «Done» в зависимости от записи.
6. Когда клиент звонит и запись показывает «Готово», верните «Готово» и удалите запись

Этот процесс немного сложнее при использовании ресурсов, но имеет некоторые преимущества

• Очередь Durable JMS будет повторно доставлена, если ваш метод бина выдаст исключение
• Очередь Durable JMS будет восстановлена, если ваш сервер перезапустится
• Используя таблицу БД вместо статических данных, вы можете поддерживать кластеризованную среду или среду с балансировкой нагрузки

Answer 2

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

Моя рекомендация - использовать ExecutorService пул потоков в стиле Java5, созданный с использованием Executors фабричного класса:

1. Когда сервер веб-службы инициализируется, создайте экземпляр ExecutorService.
2. Приходит вызов веб-службы, обработчик создает экземпляр Callable . Метод Callable.call() будет фактически вызывать бин бизнес-логики в любой форме.
3. Этот Callable передается в ExecutorService.submit(), который немедленно возвращает объект Future, представляющий конечный результат вызова. Executor начнет вызывать ваш Callable в отдельном потоке.
4. Создайте случайный токен, сохраните Future в Map с токеном в качестве ключа.
5. Вернуть токен клиенту веб-службы (шаги с 1 по 4 должны быть выполнены немедленно)
6. Позже, клиент веб-службы делает еще один вызов с запросом результата, передавая токен
7. Сервер ищет Future с помощью токена и вызывает get() на Future со значением тайм-аута, так что он только ждет ответа в течение короткого времени. Вызов get() вернет результат выполнения того, что было вызвано Callable.
   • Если ответ доступен, верните его клиенту и удалите Future из `Map.
   • В противном случае скажите клиенту вернуться позже.

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