AX2012 services - async. HTTP

[hardcore]

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

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

1. Взаимодействия в 2 стороны если клиентом является другая система например сайт и такое взаимодействие вообще разрешено административной политикой (наверно это как-то отвечает на ваш пункт с XMLHTTPRequest):
   а) Развернуть wcf сервис над ах, развернуть wcf сервис на клиенте. Клиент вызывает сервис над ах, асинхронно (имеется ввиду стандартный для .net подход
   ) запускает операцию в ах и возвращает управление, когда операция завершается, она вызывает сервис клиента передавая результат. На клиенте лежит логика по корреляции запроса с ответом.
   б) Также более красивый вариант, но не всегда реализуемый из-за ограничений со стороны админов. Реализовать сервис с CallbackContract так называемые дуплексные службы. С технической точки зрения это также вызов в 2 стороны, только коррелировать на клиенте ничего не надо, вы сделаете вызов клиентом вам вернется управления сразу, а когда сервер закончит выполнять запрос на клиенте сработает обработчик.
   
   
2. Если схема предусматривает только вызов со стороны клиента на сервер, а так обычно бывает если системы находятся «далеко друг от друга» и в компании сильна административная политика или взаимодействие между системами в разных компаниях:
   а) Способ в лоб: То вы можете также вызвать клиентом сервис над ах из него запустить операцию в ах асинхронно, по завершении выполнения просто сохранять результат в сериализованнов виде например в базе. А клиент должен периодически опрашивать сервер. Минусы подхода со стороны клиента, что придется писать логику повторного забора результата.
   
   б) Этот вариант вряд ли сходу может быть рабочий, указал только для полноты картины:
   В настройках своего wcf сервиса вы можете задать параметры InstanceContextMode= PerSession
   По умолчанию этот параметр равен perCall, то есть каждый раз когда вы делаете вызов операции на сервисе у вас создается новый экземпляр класса сервиса, если же вы поставите параметр persession то при вызове с одного клиента экземпляр класса будет один, это позволит вам также как и в первом случае вызвать код в ах и вернуть управление, а клиент должен периодически опрашивать сервис. Минусы этого подхода со стороны клиента очевидны, со стороны сервера можно напортачить с доступом к одним и тем же данным в разных потоках, т.к. wcf вам гарантирует только что для одного клиента будет работать экземпляр одного и того же сервиса но вот что вызов операций в этом экземпляре будет проходить из одно и того же потока не гарантируется.
   с) Есть еще совсем новый вариант работы через websockets но для этого нужно использовать windows server 2012 или windows 8 (сейчас только на них iis поддерживает эту технологию). Логика как и в пункте 1б + PerSession из пункта 2б, да и код похожий, и с точки зрения http взаимодействия администраторам глаза не мазолит т.к. вызовы все технически происходят со стороны клиента, такая надстройка над http вообщем.

p.s.
Вообще http устроен как протокол без состояний это дает наибольшую производительность, т.е. сервер не хранит состояние в памяти между вызовами клиента, а практически любая вещь (не считая кода 100 Continue) связанная с сессией (о том что сервер как бы помнит что это за клиент, храня его состояние в памяти постоянно) уже строится поверх http и снижает производительность.
Что касается «асинхронных http» запросов, которые вы можете делать через .net это конечно асинхронно только со стороны клиента. Клиент, делая вызов асинхронно может не ждать ответа от сервера, а продолжать исполнять код текущего потока, а ответ, который сервер обработал синхронно, приходит в другой поток клиента, после чего он становиться доступен в пользовательском обработчике. В общих чертах это можно найти здесь