Вопрос хочу оформить внешнее приложение как вебсервис а потом вызвать его из 1с вот так http://v8.1c.ru/overview/Term_000000164.htm
Допустим буду использовать java (можно и другой язык ) .
Возможно ли создать вебсервис которому не нужен тяжелый вебсервер типа apache? Т.е. чтобы это приложение я легко мог тиражировать на разные сервера

Petro123selis76,
цель перейти на Java?
Так как у вас в задаче везде "допустим". Даже ЯП.
И почему apache вдруг тяжёлый сервер.
Да задача простая, нужна замена DCom , но мультиплатформенная поскольку 1С 8.3 уже не только имеет серверную часть на Linux но и толстый клиент на Linux. Dcom был удобен для расширения функциональности 1С используя готовые методы внешних приложений (при наличии com server внешнего приложения)
Как понимаю заменой DCOm может выступать только webserice
Для вебсервиса нужен движок где я его буду публиковать, от вебсервиса мне нужна только функциональность вызова процедур и обмен параметрами (напр набор записей в виде таблички размером 1000) т.е. как пишут в доках Oracle - Service oriented web application (а не Presentation oriented)
Как понимаю в JavaVM которая скачивается с сервера Oracle такой движок не встроен по умолчанию, а если его ставить отдельно на сервера то хотелось бы ничего лишнего .

Меня прежде всего интересует интеграция 1С с другими приложениями, напр с какой нибудь шиной данных типа rabbitmq для которой вообще нет реализации Com, но есть библиотеки для java и net. В таких случаях приходится писать какой то код на языке удобного внешнему приложению
1С на Linux будет расширяться, тем более появление толстого клиента даст возможность ставить стандартный интерфейс на машины без Windows. Есть предприятия которые изначально имеют Субд Oracle в качестве основной и им не хочется специально закупать MSSQL c Win. Есть много ситуаций когда реально Windows на клиентской не требуется на машине, достаточно рабочего места с урезанным программным обеспечением. Когда начинаешь считать лицензии на решение как то резко хочется соскочить с Windows хотябы на серверной части

Petro123selis76,
при веб-сервисе накладные расходы возрастут, что опять будет минус к тупизне 1С.
надо смотреть доки по шине. Там есть коннекторы к БД, например.
смотрел уже - для MSSQL коннекторов по сути нет, а то что есть требует большего напильника. Я понимаю что на вебсервисе накладные расходы возрастают, но если работать с ним большими пакетами (т.е. вместо одной записи обмениваться пакетом из 1000) тогда это не принципиально. Просто иначе мне нужно писать внешнюю компоненту для 1С на C++ используя NativeApi 1С, а там передача сложных типов данных (типа XML сообщений ) все будет гораздо сложнее обрабатываться

Petro123selis76т.е. вместо одной записи обмениваться пакетом из 1000это как?
Вам нужна инфа по товару ID=345, а вы запросите сразу все?
Тут же БЛ, а не просто пакетная перекачка.
Если понадобится одна запись передам в табличке одну запись
Если понадо больше передам больше. Понятно что размер пакета ограничен. Так будет меньше циклов обмена с вебсервисом соответствено лучше производительность. Если чтото сразу можно сделать готовыми средствами 1С это я естественно делаю, но в процессе интеграции бывает что внешнее приложение не предоставляет ни одного интерфейса который понимает 1С (напр ни вебсервиса, ни Com , ни rest ни json и т.д. полный перечень тут http://v8.1c.ru/overview/Term_000000581.htm
и тогда приходится прокладку дописать самому.
Плохо что даже СУБД не предоставляют большей свободы - напр для MS SQL простой интеграции с RabbitMQ (некий готовый шлюз для работы с сообщениями) . У Oracle есть. В итоге приходится писать прокладку.
Пока что с точки зрения универсальности и маштабирования системный ландшафт Java выглядит предпочтительней

Petro123не верю. Там куча способов интеграции.
Какое приложение не имеет ни одного?
Пожалуйста,
http://www.rabbitmq.com/devtools.html vs http://v8.1c.ru/overview/Term_000000581.htm
com нет, простого шлюза для MS SQL нет, все остальное требует обертки в web service чтобы 1С с ним могла коммуницировать.

mad_nazgul

P.S. Если есть возможность, то не заморачивайтесь с асинхронными сервисами.
Делайте все ч/з синхронный. А асинхронность "эмулируйте" на уровне бизнес-логики.
А в чем подводный камень асинхронных сервисов?