2016-07-03 6 views
0

Я реализую веб-службу, в которой клиенты могут отправлять потенциально долгосрочные задачи, после чего они получают асинхронный токен завершения (GUID, в моем случае). Маркер может использоваться для опроса статуса операции, возможно, для получения результата вычисления или ошибки, возникшей во время вычисления. Кроме того, операция может быть отменена в любое время. В настоящее время клиенту необходимо отменить операцию после ее завершения, чтобы освободить сохраненный результат, однако я ожидаю, что также потребуется какая-то форма сбора мусора результатов.Есть ли (широко внедряемый) WS- * стандарт для длительных асинхронных операций?

Эта настройка является нетривиальной для клиента: ей необходимо периодически хранить маркер GUID, периодически опросить, не забудьте отменить операцию, если она больше не нужна, обрабатывать асинхронные ошибки и т. Д. Если потребуется некоторая проверка подлинности (WS-Security, WS-Trust), ситуация будет еще более сложной, например, должен быть запрещен доступ к статусу операции, запущенной другим пользователем.

Существует ли широко доступный, совместимый WS- * стандарт для таких асинхронных операций? Я хотел бы иметь возможность вызывать сервер, по крайней мере, из WCF и клиента JAX-WS, и, возможно, использовать асинхронные задания в сочетании с другими стандартами WS- *. Роллинг моего опроса не имеет большого значения, однако я бы не хотел изобретать велосипед.

+0

Это был случай, когда вы использовали бы WCF вместе с многолетними рабочими процессами Windows Workflow Foundation под Microsoft Windows Server AppFabric. К сожалению, я думаю, что WS AppFabric был отмечен для прекращения. – MickyD

ответ

1

Не совсем уверен, что стандарты WS- * для этого. Недавно наша команда использовала Hangfire для реализации некоторой функции, аналогичной вашей.

Как вы можете легко интегрировать Hangfire с помощью кодов, вы можете предоставить задание, представляющее собой интерфейс, и реализовать некоторую логику для генерации GUID и очереди задачи на сервер Hangfire, а затем реализовать свое требование в бизнес-логике.

+0

Спасибо, это действительно хороший инструмент, хотя и немного для меня. Я рассмотрю hangfire для реализации очереди заданий, но в настоящее время моя основная проблема заключается в реализации интерфейса представления задания/статуса, который может быть доступен как для .NET, так и для Java. –

+0

@ KristófMarussy Интерфейс, который может быть доступен как для .Net, так и для Java, может быть определен в вашем wsdl/xsd. Попробуйте этот подход: когда задание отправляется, закажите задание на Hangfire и верните GUID клиенту, когда клиент запрашивает статус конкретного задания (используя GUID в качестве параметров запроса), вы можете получить конкретный статус задания из Hangfire, или вы можете создать таблицу состояния, которая будет использоваться для работы Hangfire и вашего уровня обслуживания, и вернуть статус на основе запрошенного GUID. –

+0

Да, я уже определил свой интерфейс. Я ищу стандартизованный интерфейс, поэтому я не изобретаю велосипед. Но если ни один из них не существует (или, по крайней мере, ни один из них не будет реализован достаточно широко, чтобы быть полезным, я не хочу добавлять интересные заголовки SOAP только ради него), тогда я буду придерживаться собственного интерфейса. –

Смежные вопросы