Доброго времени суток!
Есть мысль сделать обмен между одинаковыми удаленными базами через COM-запросы и VPN. Интернет выделенный, стабильный. Взлетит?

(0) Почему бы ему не взлететь? Особенно если инет действительно стабильный.

ЗЫ. Но вообще рекомендуется пользоваться ВЕБ-сервисами. Оно хоть и медленней и гемора больше, но зато надежней.

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

(1) Кста, а кушает ли лицензию WS-соединение?

(3) по идее должно кушать

(2)
1. Зачем программистам знать тонкости апача? Оно стсуко работает так что раз настроил и забыл.

2. "простое и прозрачное решение" Для обмена через инет как раз и будут ВЕБ-сервисы. А не КОМ поверх ВПН.

(3) Да. Равно как и КОМ.

(0) Работает, но очень медленно. Сейчас перешли 8,3 и переделываем на ВЕБ-сервисы.

(4) COM съест, WS - нет.

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

(6) да, там если com не на этом компьютере, сам процесс секунд 20 запускается.

+(4),(7) Хотя вру :( Оба жрут

(8) Большие данные это сколько? У меня максимальный пакет где-то 10 мегабайт. Апач настройки по умолчанию. Стоит на винде.Проблем нет.

(8) так не передавайте большие данные

(8) Всех тонкостей - это время таймаута в 20 мин. Все.
Если обслуживание запроса требует большего времени - нужно менять логику работы.

(6) что съедает больше всего времени, соединение, запрос или что-то другое?

Веб-сервисы и фоновые задания не жрут лицензий.

(11) Дело не в размере передаваемых данных. Код обработки метода ВЕБ-сервиса может выполняться долго.

(14) запросы разные бывают. Например, что-то у вас в запросе там набыдлокодили, вот у вас уже и апач виноват.

(9) а если сериализовывать его и пытаться при следующем соединении восстановить?

+ (16) Апач считает все, что не закрылось в течении 20 мин. зависшим. И сбрасывает соединение. 1С об этом не знает и клиент продолжает ждать ответа от сервера.

(14) Инициализация соединения долго. И сама передача как-то вяло идет. Локально на прядок быстрее. Сильно не копали.
В ВЕБ как не странно пофигу локально или через сеть гнать скорость одинаковая, но чуть медленей локального COM соединения.

(11) больше 100 МБ

(16) Код весь максимально оптимизирован. Предел 30 секунд.  Так как COM тормозило не по детски.

(18) я делал так, но сериализация таких соединений - это незадокументированная фича, сегодня работает, а завтра выйдет новая платформа, а там это прикрыли.

(18) Можете сериализовать и записать на флешку ))).
Только 1С на стороне сервера сеанс убъет - хоть 100500 раз десериализуйтесь.

(19) спасибо, проверю

(21) Тогда надо рубить. Апач не любит толстые потоки.

(26) видимо все к этому идет

тормоза в веб сервисах могут быть от того что сидит в используемых пространствах имен, у себя за 3 дня урезали их по миниму, получилось с полутора минут до одной-трех сек передачу ВСЕХ остатков и резервов оптимизировать, а на СОМе таких результатов и близко не было

сидит в используемых пространствах имен - подробней можно?

(28) спасибо, не знал

(0) А еще лучше через HTTPсервисы.

(5) "Зачем программистам знать тонкости апача?" - тем более, что там и тонкостей то нет. Практически все из коробки запускается.

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