ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

[gl00mie]

Цитата:

Сообщение от 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 раз больше пивных банок. Такой проект требует совершенно иного планирования и конструирования.

[mazzy]

Цитата:

Сообщение от gl00mie

...тоже не беспокоит?

конечно же беспокоит.
поэтому и была создана тема.

что ж, критика навиного подхода к передаче данных между разными системами - зачетная.
именно поэтому и создана тема "как правильно"

каковы твои предложения?
для начала какую именно технологию ты называешь асинхронным обменом?

Цитата:

Сообщение от gl00mie

...при асинхронном обмене

[mazzy]

Цитата:

Сообщение от gl00mie

Разбивать ли коллекцию из 100500 элементов на блоки при передаче? Решать, конечно, на местах

собственно тема КАК правильно решить на местах?

Цитата:

Сообщение от gl00mie

но я бы тут вспомнил про то, что в ядре, начиная с AX2009, есть ограничение на

а с чего ты решил, что об этом кто-то забыл?

Цитата:

Сообщение от gl00mie

и не отправлять все 100500 элементов, скажем, одним куском повторно

а кто-то говорил "одним куском"?!

[gl00mie]

Цитата:

Сообщение от mazzy

а кто-то говорил "одним куском"?!

Ну вот же 2-я опция из 3-х в исходном сообщении

Цитата:

Сообщение от mazzy

передавать по одном элементу - слишком много накладных расходов.

передавать всю коллекцию - в момент передачи все это богатство превратится в XML и разорвет все внутренние буфера.

делить на чанки и передавать чанками по несколько сотен элементов - надо возиться и тоже никакой гарантии, что не разорвет внутренние буфера.

Цитата:

Сообщение от mazzy

собственно тема КАК правильно решить на местах?

Если речь про разбивку 100500 сообщений на пачки, то - принимать во внимание имеющиеся ограничения в ядре и смотреть по опыту, какой размер лучше подходит в рамках имеющихся ограничений. Поскольку неизвестно, что именно за данные надо передавать и как обрабатывать на принимающей стороне, то сложно тут придумать что-то универсальное на все случаи жизни.
Если уж говорить про "ручную" разбивку сообщений на пачки, то можно пойти таким путем. Допустим, ограничение, которое мы хотим "соблюсти", - это заранее известный размер буфера сериализованных сообщений на принимающей стороне, при этом размеры отдельных сообщений нам заранее неизвестны. Выходит, нам надо адаптивно менять размер пачки так, чтобы он каждый раз был максимально близок к размеру буфера (ограничению), но не превышал его. Под такие требования подходит вариант, реализованный в 12-ке для разноски журналов ГК с распараллеливанием в пакетном режиме. Там аналогично попытались соблюсти баланс между распараллеливанием разноски и накладными расходами, связанными с большим числом пакетных задач.
Суть подхода в том, что есть "сборщик" условных пачек, которому по одному за раз подаются элементы (журналы для разноски или сообщения в нашем случае). Сборщик принимает решение, добавить очередной элемент в текущую пачку или же завершить ее формирование и добавить очередной элемент уже в новую пачку. В случае журналов ГК сборщик смотрит на суммарное количество строк журналов в текущей пачке - эти журналы будут последовательно разноситься в одной пакетной задаче. В случае пакетирования сообщений сборщик может смотреть на суммарный размер сериализованных сообщений в текущей пачке с учетом ограничения на размер буфера и условного размера закрывающих XML-тегов для пачки. Такой подход обычно работает более гибко, чем грубое поштучное деление сообщений на пачки.

Цитата:

Сообщение от mazzy

для начала какую именно технологию ты называешь асинхронным обменом?

Асинхронным я называю обмен, который позволяет системе-отправителю не ждать ответа системы-получателя (этот ответ при необходимости может быть получен в другое время), а системе-получателю позволяет обрабатывать входящие сообщения в отложенном режиме и с той скоростью, которая комфортна системе-получателю, а не системе-отправителю. Это подразумевает, что:

• сообщения обычно обрабатываются медленнее либо с меньшим параллелизмом, чем формируются и отправляются
• желательно сгладить для системы-получателя пиковые нагрузки и/или управлять ресурсами, выделяемыми на обработку того или иного типа сообщений
• если система-получатель недоступна на момент отправки сообщения, это не должно быть препятствием для системы-отправителя
• между отправителем и получателем есть некая буферная система (stream, очередь, брокер сообщений, как угодно).

подразумевается, что буферная система:

• способна принимать сообщения заведомо быстрее, чем они формируются системой-отправителем
• обеспечивает более высокую доступность своих сервисов, чем система-получатель
• обладает достаточными ресурсами для накопления передаваемых сообщений в случае пиковых нагрузок или недоступности системы-получателя
• может поставлять данные (счетчики производительности) для систем мониторинга
• в качестве бонуса позволяет сохранять передаваемые сообщения для разбора полетов и т.п.

С некоторой натяжкой в качестве буферной системы можно рассматривать файл-сервер Но мне в последнее время, особенно на всяких там "сложных ИТ-ландшафтах" импанируют RabbitMQ и Kafka. Они позволяют реализовать своего рода амортизаторы между разными системами, особенно когда системам выделены разные ресурсы, возможны пиковые нагрузки, периоды недоступности и т.п.

[mazzy]

Цитата:

Сообщение от gl00mie

Ну вот же 2-я опция из 3-х в исходном сообщении

Цитата:

Сообщение от gl00mie

Если речь про разбивку 100500 сообщений на пачки, то

не-не-не-не!
еще раз: посмотри как сформулирован вопрос.
я сформулировал ровно то, что хотел сформулировать и постарался убрать из вопроса то, что может ограничить решение.

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

давайте я таки скажу какое решение я бы считал идеальным:

1. отправитель готовит коллекцию типизированных объектов произвольного размера
2. отправитель вызывает какой-нибудь специальный метод
3. транспортный уровень, зная о своих возможностях и о размерах буферов, сам организует поток (stream), сам разбивает на пачки, сам их их шифрует, сам собирает эти пачки на приемнике
4. приемник получает собранную коллекцию типизированных объектов

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

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

Цитата:

Сообщение от gl00mie

Поскольку неизвестно, что именно за данные надо передавать и как обрабатывать на принимающей стороне, то сложно тут придумать что-то универсальное на все случаи жизни.

Блин, ты как продавец говоришь... совсем невкусно.
если у тебя есть варианты, то предложи: вот такой случай - вот так то, вот такой случай - вот так.

я же не вижу ни универсальных, ни частных хороших решений.
поэтому и спрашиваю.

Цитата:

Сообщение от gl00mie

Под такие требования подходит вариант, реализованный в 12-ке для разноски журналов ГК с распараллеливанием в пакетном режиме. Там аналогично попытались соблюсти баланс между распараллеливанием разноски и накладными расходами, связанными с большим числом пакетных задач.
Суть подхода в том, что есть "сборщик" условных пачек, которому по одному за раз подаются элементы (журналы для разноски или сообщения в нашем случае). Сборщик принимает решение, добавить очередной элемент в текущую пачку или же завершить ее формирование и добавить очередной элемент уже в новую пачку. В случае журналов ГК сборщик смотрит на суммарное количество строк журналов в текущей пачке - эти журналы будут последовательно разноситься в одной пакетной задаче. В случае пакетирования сообщений сборщик может смотреть на суммарный размер сериализованных сообщений в текущей пачке с учетом ограничения на размер буфера и условного размера закрывающих XML-тегов для пачки. Такой подход обычно работает более гибко, чем грубое поштучное деление сообщений на пачки.

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

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

Цитата:

Сообщение от gl00mie

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

а... понятно.

обрати внимание, что в вопросе используется слово "передать", а не слово "обмен". в вопросе НЕТ ни слова о ждать.

ты как Vadik. только он постоянно говорил что данные должны "запрашиваться" вместо "передаваться".

Ребяты, пожалуйста, прочтите вопрос в самом начале темы.

Ребяты, пожалуйста, не предполагайте, что кто-то забыл об ответах и подтверждениях о приеме данных. Просто вопрос данной темы:

как правильно передать 100500 элементов коллекции через WCF или любой другой брокер в ax2012,ax2009?