Практика асинхронных и синхронных веб-сервисов?

Question

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

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

Как лучше всего реализовать асинхронные веб-службы?

Answer 1

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

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

Лично я рассматриваю возможность создания второго определения WSDL для асинхронных ответов (что может произойти от нескольких секунд до нескольких часов позже запроса, в зависимости от нагрузки на указанное внутреннее хранилище.) Клиенты, вызывающие наши веб-службы, должны будут, в свою очередь, внедрить веб-сервис, используя этот «2-й WSDL», к которым мы выступаем в качестве клиентов.

Мне было бы интересно узнать направления, которые вы изучаете.