da0c

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

Классическое решение от 1С — Битрикс использует следующую схему — выгрузка из 1С в CommerceML (ну в смысле в XML стандартизированного формата CommerceML) и загрузка этого дела на сайт.
Таким образом вы можете загрузить на сайт актуальный ассортимент, прайс лист и остатки на складах.
С сайта вы можете также в XML выгрузить нужные вам счета/заказы и загрузить их в 1С.
Механизм, который позволяет 1С выполнять обмен данными через сереализацию в XML называется конвертацией данных или обменом, конкретный обмен задается правилами обмена (тоже записанными в XML)/ Единтственное, вам конено придется настроить правила обмена, так чтобы 1С отдавала нужные вам данные, а также настроить правила загрузки данных с сайта. Настройка правил обычно выполняется на основе типового шаблона с использованием для допиливания специальной конфигурации, которая так и называется — «Конвертация данных».

Обмен через XML в этом слчае предпочтителен, т.к. вас наверное сервер 1С и web сервер тереторриально разнесены. Т.е. в таком случае COM однозначно не катит, возможен конечно доступ непосредственно к SQL серверу на котором лжит 1С — но здесь тоже непросто, как минимум, для того чтобвы записать счета/заявки в напрямую в SQL базу 1С придется поколдовать (хотя это возможно, и мы так делали).
Дак, как напиасно выше 1С позволяет использовать SOA обертку, но работа с ней требует большего кода на стороне 1С и в целом более сложный механизм, однако позволяет работать с данным полность в реальном времени. Т.е. если в случае выгрзки XML вы можете обновлять на сайте остатки насайте каждый час, то при использовании веб сервиса 1С вы бдете видеть всегда актуальные остатки. Как правило такой оперативности не требуется, если же это то, что вам надо — пишите, распишу иеханизм веб сервисов.

Если требуется более подробный совет пишите в личку — посоветуем, а если надо и поможем;-)

Да, второй вариант с related UDP предпочтительнее. Есть однако над чем подумать.
1. А клиенты по UDP соединиться смогут (нет ли фаервола)? Можно конечно использовать UDP 53…
2. А клиентов вы как будете распространять? При работе по HTTP клиент получается браузерный, т.е. распространение как бы на халяву. Любой клиент на основе сокетов придется распространять в бинарном виде.
3. Еще стоит подумать об udp vs tcp. Если у вас сервер и клиент в пределах одной локалки, то однозначно — udp. Если вам важен порядок получения пакетов клиентом по интернет, то придется реализовывать какой-то свой протокол с нумерацией внутри udp.
Как показывает практика uTorrent, переимплементация TCP на UDP доставляет профит. Но нужно трезво оценивать, что 20% выигрыша в скорости будут стоить 80% усложнения кода.
Если писать свой транспорт с гарантией доставки не хочется, а гарантия доставки тем не менее нужна, то можно использовать TCP, забив на небольшой оверхед. А может и правда взять uTP.