Передача больших пакетов через веб-сервисы
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Данная методика давно уже используется во многих типовых решения для обмена с мобильным клиентом. Только регистр там называется ОчередиСообщений. Ну нужно сказать что деление файла на части хоть и позволяет передать много данных, но существенно тормозит процесс обмена. Все как всегда, что быстрее работать с одним большим файлом или с кучей мелких.
А еще до мобильной - это есть все в бсп :)
Но есть и другое решение - вам надо с УТП забрать файл в 1Гб, и поместить его, например, в документооборот, не важно.
Действия такие - документооборот подключается к УТП (возможно по инициализации самой УТП) и забирает оттуда файл в 1Гб без ограничений :)
Но есть и другое решение - вам надо с УТП забрать файл в 1Гб, и поместить его, например, в документооборот, не важно.
Действия такие - документооборот подключается к УТП (возможно по инициализации самой УТП) и забирает оттуда файл в 1Гб без ограничений :)
(5) bonv, если использовать бинарный тип (hexBinary), то накладные расходы SOAP будут всего лишь в добавлении envelope-обвязки пакета - можно пренебречь. Сам к сожалению не экспериментировал, так как мне были доступны для передачи файлы кодированные в Base64 (как раз эти самые потери 33% на увеличении объема), но если возможность в платформе есть, то и имеется вероятность отличная от нуля, что это работает.
При передаче файлов POST-ом по протоколу HTTP та же петрушка, что и при SOAP - данные часто передают типом application/x-www-form-urlencoded
При передаче файлов POST-ом по протоколу HTTP та же петрушка, что и при SOAP - данные часто передают типом application/x-www-form-urlencoded
(13) Dementor, Вы правы, сам SOAPовский конверт имеет незначительный вес, а вот преобразование в base64 увеличивает размер передаваемых данных на треть.
(14) premier, проще отслеживать состояние передачи пакета, можно запросами платформы получать состояния передачи пакетов и т.д., а с каталогом пришлось бы для этого делать "извраты" с чтением файлов и т.д. Сами данные пакета не обязательно записывать в регистр сведений, можно в нем хранить лишь путь к файлу части пакета на диске (что-то вроде хранения файлов в томах). На рабочей базе лучше реализовать периодическую очистку этого регистра, чтобы старые пакеты в нем не хранились долго.
Вариантов реализации масса)
(14) premier, проще отслеживать состояние передачи пакета, можно запросами платформы получать состояния передачи пакетов и т.д., а с каталогом пришлось бы для этого делать "извраты" с чтением файлов и т.д. Сами данные пакета не обязательно записывать в регистр сведений, можно в нем хранить лишь путь к файлу части пакета на диске (что-то вроде хранения файлов в томах). На рабочей базе лучше реализовать периодическую очистку этого регистра, чтобы старые пакеты в нем не хранились долго.
Вариантов реализации масса)
(13) срочно учить матчасть!
Если использовать hexBinary, то расходы будут 100%. hexBinary использует для отображения одного байта 2 символа.
А вот в платформе еще пока нет. Так что только голый HTTP.
А application/x-www-form-urlencoded то тут причем. Данный формат предназначен для передачи параметров веб-формы. Для передачи бинарных данных никто его в здравом уме использовать не будет.
если использовать бинарный тип (hexBinary), то накладные расходы SOAP будут всего лишь в добавлении envelope-обвязки пакета - можно пренебречь
Если использовать hexBinary, то расходы будут 100%. hexBinary использует для отображения одного байта 2 символа.
А вот в платформе еще пока нет. Так что только голый HTTP.
При передаче файлов POST-ом по протоколу HTTP та же петрушка, что и при SOAP - данные часто передают типом application/x-www-form-urlencoded
А application/x-www-form-urlencoded то тут причем. Данный формат предназначен для передачи параметров веб-формы. Для передачи бинарных данных никто его в здравом уме использовать не будет.
Круто! Вопрос только один: А нафига зачем??? Одно дело упростить себе жизнь и использовать SOAP для построения событийной модели обмена... Другое дело лить через http протокол файлы. Ну и выгружайте тогда уж в файл, притом лучше не XML, а хотя бы FI тогда уж... а по SOAP передавайте ссылку на него...
(7) comol, сразу забыл ответить, сорри)
Так то оно так, но если переход на обмен через веб-сервисы выполняется со старого транспорта, который выполнял выгрузку в XML, то время на изменение обмена может очень дорого стоить компании. Компромиссный вариант - изменить вид транспорта и немного механизмы обработки сообщений, вместо переписки основной части выгрузки и загрузки данных.
Так то оно так, но если переход на обмен через веб-сервисы выполняется со старого транспорта, который выполнял выгрузку в XML, то время на изменение обмена может очень дорого стоить компании. Компромиссный вариант - изменить вид транспорта и немного механизмы обработки сообщений, вместо переписки основной части выгрузки и загрузки данных.
В одной своей разработке тоже уткнулся в относительно большие размеры сообщений, передаваемых через SOAP (в моем случае 7-8 МБ).
Загрузка с тестового сервера Амазон во Франкфурте не прошла: отвалилось по таймауту.
Стал на стороне сервера сжимать ответ сервера в ZIP и передавать его тем же SOAP как base64Binary (. Средний размер файла оказался уже около 500 КБ. Распаковка в XML и парсинг в XDTO объект проблем не вызвала, поскольку сам объект WSProxy предоставляет заодно и фабрику XDTO, которой уже можно парсить разжатые ответы.
Протестировал то же самое со сжатием FastInfoSet вместо XML - выигрыш получился незначительный.
Если вместо SOAP использовать HTTP, тоже будет некоторый выигрыш.
А идеально (в моем случае, по крайней мере) использовать рецепт из (7), причем даже асинхронный. Т.е. сервер сразу же возвращает URL файла. А клиент периодически проверяет наличие этого файла, и, как только тот стал доступен, начинает скачивать. Возможно, уже с разбивкой на пакеты.
В любом случае за тему плюс ))
Загрузка с тестового сервера Амазон во Франкфурте не прошла: отвалилось по таймауту.
Стал на стороне сервера сжимать ответ сервера в ZIP и передавать его тем же SOAP как base64Binary (. Средний размер файла оказался уже около 500 КБ. Распаковка в XML и парсинг в XDTO объект проблем не вызвала, поскольку сам объект WSProxy предоставляет заодно и фабрику XDTO, которой уже можно парсить разжатые ответы.
Протестировал то же самое со сжатием FastInfoSet вместо XML - выигрыш получился незначительный.
Если вместо SOAP использовать HTTP, тоже будет некоторый выигрыш.
А идеально (в моем случае, по крайней мере) использовать рецепт из (7), причем даже асинхронный. Т.е. сервер сразу же возвращает URL файла. А клиент периодически проверяет наличие этого файла, и, как только тот стал доступен, начинает скачивать. Возможно, уже с разбивкой на пакеты.
В любом случае за тему плюс ))
Идея интересная, если делать тиражное решение для абстрактного клиента, на инфраструктуру которого не возможно повлиять.
Но на своем опыте могу сказать - при задаче частого обмена большими файлами проще в веб-сервере убрать ограничение для опубликованной базы.
Но на своем опыте могу сказать - при задаче частого обмена большими файлами проще в веб-сервере убрать ограничение для опубликованной базы.
Вопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|