Web-сервис(WCF) --> 1C -->Web-сервис(WCF) - реально? #679942

Есть некий сервер (свой), который должен выдавать 1С-у некую инфу. Инфа - список объектов. Объекты состоят из простых типов. Объектов много, все типы разные, все распиханы по полям одного класса (траспорт для всего этого). Типа такого: Контрагенты   Пупкин   Петров Номенклатура И т.д. Сейчас обмен происходит через SQL - данные выкладываются в таблицы, 1С-ка их забирает и выкладывает обратно. По ряду причин это не нравится. Хочется замутить всё это через WEB-сервис. Сервис планируется поднять НЕ НА стороне 1С. Соответственно - 1С-ка должна вызывать метод сервиса, получать этот транспортный класс, преобразовывать его, и ВЫДАВАТЬ ОТВЕТ в виде того же заполненного транспортного класса. Версия 1С - 8.1 Это вообще реально? Почитал про WSDL-схемы - хочется перекреститься и забыть об этом.

Непонятно, чем так отталкивает WSDL. Это ведь именно то, о чём Вы пишете - описание протокола обмена с Web-сервисом.

что принципиально мешает реализовать какую-то свою схему если не нравится WSDL? 1С прекрасно работает с данными по банальному протоколу HTTP. разработать API и отдавать данные в соответствии с собственной спецификацией.

покури, например, "json enabled wcf service"...

Отталкивает возможными проблемами - типа очень сложно скормить  WDSL описание 1С-ке. Без видимых причин. Насчет банального протокола HTTP - вы имеете ввиду - просто по запросу получить XMLJSON файл, распарсить его, обработать и такой же файл заслать в ответ? А что в таком случае должен отдавать сервер? Тоже файл? Надо ли его специально в файл преобразовывать?  Ведь WCF-сервис делает это сам.. И что должно стоять на входе (прием данных) у сервера? Где можно почитать об этом? JSON - потому что он "легче" XML?

А зачем тогда люди так мучаются с WS-ссылками - какие-то шаманства, какие-то засекреченные разработчики в 1С? Получил файл по HTTP - запросу - распарсил - и гуляй Вася.

Да Вася. Все дело в типизации того, что ты передаешь. 1С WSDL сделала как XTDO, но по своим спецификам. Вот все и мучаются.

Потому что 1С выбрала интересную схему. Под себя, любимую. А не любимые - мучаются :-) Если не хочется возиться с заморочками 1С - то решение в . HTTP - никто никого ни в чём не ограничивает. Правда, придётся чуток потрудится в определении и реализации протокола. Но именно "чуток".

Можно через Rabbit сделать, была публикация на инфосрарте как именно, но уже она не активна к сожалению. Плюсы: очередь, произвольный формат сообщений, скорость высокая. Минусы пока не обнаружены.

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