Есть некий сервер (свой), который должен выдавать 1С-у некую инфу. Инфа - список объектов. Объекты состоят из простых типов. Объектов много, все типы разные, все распиханы по полям одного класса (траспорт для всего этого).

Типа такого:
Контрагенты
  Пупкин
  Петров
Номенклатура
  Карандаш
  Линейка

И т.д.

Сейчас обмен происходит через SQL - данные выкладываются в таблицы, 1С-ка их забирает и выкладывает обратно. По ряду причин это не нравится. Хочется замутить всё это через WEB-сервис.

Сервис планируется поднять НЕ НА стороне 1С. Соответственно - 1С-ка должна вызывать метод сервиса, получать этот транспортный класс, преобразовывать его, и ВЫДАВАТЬ ОТВЕТ в виде того же заполненного транспортного класса.

Версия 1С - 8.1

Это вообще реально? Почитал про WSDL-схемы - хочется перекреститься и забыть об этом.

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

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

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

(1)
Отталкивает возможными проблемами - типа очень сложно скормить  WDSL описание 1С-ке. Без видимых причин.

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

Где можно почитать об этом?

(3)
JSON - потому что он "легче" XML?

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

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

(5) Потому что 1С выбрала интересную схему. Под себя, любимую. А не любимые - мучаются :-)

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

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

(4) вот например на хабре статья о проектировании API http://habrahabr.ru/post/181988/

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