Цитата:
Сообщение от
mazzy
всё ещё надеюсь услышать мнения по вопросу:
ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?
По-моему, вся тема - про то, что
ax2012,ax2009: правильно передать 100500 элементов коллекции НЕ через WCF 
Цитата:
Сообщение от
mazzy
дополнительные вводные, которые были уточнены по ходу ветки и в личной переписке:
* "передать" в смысле "отправить"
* в аксапте есть recId и нумераторы
* в аксапте нет встроенной поддержки потоков (stream).
* аксапта 2009 работает на .net 3.5
* аксапта 2012 работает на .net 4.0 (не 4.5)
* размер элемента коллекции в Аксапте до 8Кб
* размер коллекции до 100500 элементов, но вряд ли больше 2^32
Мне лично думается, что как только возникает 100500 элементов для передачи, интеграция должна становиться асинхронной, а связь ax2012 и ax2009 через WCF как-то не очень ложится на идею асинхронного обмена (без собственных dll, "
и чтобы эти собственные dll'ки работали в адресном пространстве аксапты"). Это вроде само собой разумеется уже: если требуется обрабатывать в системе много документов, то надо писать пакетную обработку с распараллеливанием. Если требуется передавать между системами большие объемы данных, то надо делать асинхронный обмен.
На тему проектирования интеграций
есть хорошая статья у
Дениса Трунина, где он предлагает для начала определиться с такими моментами:
- Топология решения интеграции
- Требования для потока данных
- Анализ свойств потока данных
- Определение качества обслуживания (QoS)
- Производительность
- Доступность и надежность
- Безопасность
- Масштабируемость
- Логирование и м... "неподдельность" (nonrepudiation)
И уже по совокупности требований будет ясно, WCF это окажется или не WCF...
Цитата:
Сообщение от
mazzy
* вместо WCF можно обсуждать любой другой брокер/транспорт
* предполагаем, что middlware отсутствует. но мы можем сделать любой
* для простоты предполагаем, что все компоненты под нашим контролем и вопросы безопасности решены
что беспокоит в первую очередь - накладные расходы на передачу каждого сообщения.
А что 100500 элементов будут парситься/валидироваться/обрабатываться в один поток слишком медленно - не беспокоит?
А как при распараллеливании приемки данных не забить все доступные потоки на пакетном сервере/серверах (привет от закрытия склада), тоже не беспокоит?
Цитата:
Сообщение от
mazzy
лично я не вижу, как брокер/транспорт может принципиально повлиять на принимающую сторону. парсинг и валидация на принимающей стороне будут плюс-минус одинаковыми.
Брокер/транспорт при
асинхронном обмене даст принимающей стороне возможность обрабатывать сообщения тогда и в таком темпе, в каком ей комфортно, не просаживая другие поддерживаемые бизнес-процессы. А стороне-отправителю даст возможность не ждать ответа и не отправлять все 100500 элементов, скажем, одним куском повторно, если у принимающей стороны что-то не заладилось.
В обсуждении много говорилось про очереди, шины данных и т.п. По-моему, если нужно перебрасывать между двумя системами такие объемы данных, стоит посмотреть в сторону какого-нить RabbitMQ хотя бы. Разбивать ли коллекцию из 100500 элементов на блоки при передаче? Решать, конечно, на местах, но я бы тут вспомнил про то, что в ядре, начиная с AX2009, есть ограничение на размер буфера под значимые типы (тот же string), которое по умолчанию, кажется, равно 1Мб - см.
Падает клиент при прикреплении файла. Так что если утоптать 100500 элементов в один большой XML/JSON, то на принимающей стороне с ним может быть
непросто работать. Я бы в связи с этим постарался разбивать передаваемые данные на блоки меньше 1Мб каждый.
Цитата:
Сообщение от
CDR
Я так полагаю, вопрос "ax2012,ax2009: как правильно передать 1 элемент через WCF?" уже успешно решен?
Кажется, у Макконнелла в Code Complete было:
Цитата:
Для построения метровой башни требуется твердая рука, ровная поверхность и 10 пивных банок, для башни же в 100 раз более высокой недостаточно иметь в 100 раз больше пивных банок. Такой проект требует совершенно иного планирования и конструирования.