В одной локальной сети находятся 3 конфигурации: ERP, ДО и третья самописная, которая общается с внешним миром через http сервисы. В зависимости от того, что запросили у третьей базы, она обращается либо к ERP, либо к ДО. Соответственно не могу определиться, что же лучше использовать для связи между конфигурациями веб-сервис или ком-соединение? Какие плюсы\минусы будут?
Насколько помню из собственного опыта, ком-соединение дольше коннектит к базе приемнику, нежели обращение к веб-сервису. Но может это было конкретно в том случае. Еще из плюсов в сторону веб-сервисов, это, на мой взгляд, что их проще отлаживать. Ну и мелочи в виде требования к одинаковой платформе и вообще устаревшей технологии ком-соединения.
Но может все таки я чего-то не знаю? )

У тебя лицензий то хватит?
Представь что "запросили у третьей базы" одновременно аж 100 клиентов и "она обращается либо к ERP, либо к ДО" через COM.

Вопрос: Сколько лицензий потребуется?

ВЕБ! ептыть

Имхо надо опубликовать http сервисы все три базы и делать на них отдельные запросы "из внешнего мира".
Для безопасности можно перед ними воткнуть nginx с авторизацией и чтобы только нужные запросы пропускал.

И да он же может api запросов преобразовывать в нужные виды к разным базам.
Например запрашивают /base/doc будет proxy_pass на ERP, /base/dir на ДО и т.д.

А запросы между конфами по запросу извне это имхо изврат редкостный.
Другое дело если данные нужны самописке в базу тогда дергать через сервисы другие конфы нормально.

(1) КОМ жрет лицензию, а веб-сервис не жрет?

(3) Простое преобразование не подойдет, есть, например, запрос из вне, который должен в одной базе что-то найти, в зависимости от того, что нашел, записать что-то в другую базу и ответить во вне. Есть запросы, которые идут только в ЕРП или только в ДО. Короче проще вынести логику в третью базу, которая будет рулить запросами.

ну так повесь http сервисы на до и ерп. пусть нетленка решает и долбается в до и ерп. с улицы запросы все в нетленку.

(6) Так и будет, все запросы с улицы в нетленку. Вопрос в том, как лучше общаться нетленке с ДО и ЕРП - через ком соединение или через веб-сервисы?

(7) Тебе же сказали никак. Пусть снаружи сразу в ДО или ERP долбаются если нужны данные оттуда.

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

(7) там программы идентичны полностью, никаких отличий нет. Оформляешь процедуру например, которая всё это делает, и ее включаешь или туда или сюда. Всё одинаково. Отличия те которые в (0), ну и насчет лицензий, всё в пользу вебсервиса.

(5) "веб-сервис не жрет" - не жрет

(0) COM - это гарантированные пляски с бубном при обновлении платформы.

(5) >Простое преобразование не подойдет, есть, например, запрос из вне, который должен в одной базе что-то найти, в зависимости от того, что нашел, записать что-то в другую базу и ответить во вне. Есть запросы, которые идут только в ЕРП или только в ДО. Короче проще вынести логику в третью базу, которая будет рулить запросами.

Слишком сложная логика упрощай и разноси операции.
Если самописка периодически обращается к ДО/ERP это нормально, внешние запросы к самописке тоже нормально.
Но разнеси обращение извне к самописке и самописка дергает ДО/ERP, это разные потоки/процессы должно быть.

Т.е. внешний клиент дернул самописку, она нечто записала у себя.
Затем самописка планово начинает обработку записанного, обращается к ДО/ERP сохраняет у себя.
При следующем обращении клиента ему выдают данные.

Принцип понятен? Если запрашивается некий отчет, то он сначала формируется и как будет готов уже можно скачивать. А не так что ждемс пока отчет сформируется.

(12) Так и делаю на очередях )

Забудьте про ком

А между базами есть какая-то принципиальная разница http или web сервис использовать? Не будет ли http быстрее, так как там нету авторизации на клиенте?

http://v8.1c.ru/o7/201312http/

По сравнению с имеющимися в платформе SOAP web-сервисами, HTTP-сервисы имеют ряд преимуществ:

Простота программирования клиента таких сервисов;
Потенциально меньший объем передаваемых данных;
Потенциально меньшая вычислительная нагрузка;
HTTP-сервисы ориентированы на «ресурсы», в то время как SOAP сервисы ориентированы на «действия».

(16) Что значит это загадочное "HTTP-сервисы ориентированы на «ресурсы», в то время как SOAP сервисы ориентированы на «действия»." ?

Делай веб-сервисы, полет нормальный

(17) HTTP это запрос текстом (внутри текста может быть и xml и json и бинарные данные в Base64) и ответ текстом.
SOAP больше всего похоже на удаленное выполнение процедур/функций, вызов только разрешенных команд с передачей параметров и получение ответа.

(19)+ Для разделения "команд" в простом HTTP придумали REST.
Это когда GET/PUT/POST/DELETE и URL пути разные через /

(19) Ну так, что в веб-сервисе, что в хттп я могу вызвать только те процедуры и функции, которые объявлены. А параметры функций так же передаются простым текстом в POST запросе в случае веб-сервиса и POST либо GET, в случае хттп-сервиса

(21) Назначение одно, реализация разная.
SOAP это строгий RPC.
HTTP по REST это просто набор неких необязательных соглашений.

https://habr.com/ru/post/75248/ для общего развития

(0) Интерфейс OData не рассматриваете?

(24) ODATA это получение данных и их запись.
Оно сложные запросы/отчеты не умеет же, один хрен писать на 1С HTTP или ВЕБ-сервису и публиковать.

(24) OData еще сырая у 1С. Права на все объекты, которые опубликованы будут доступны всем пользователям полностью.
например есть Вася Пупкин, с правами на чтение одного справочника. Если он узнает адрес сервиса, он сможет зайти и записать все что хочешь в объекты, которые опубликованы