собственно у нас ваяют систему на оракле, меня напрягают на создание обмена с 1с.

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

накидайте ссылок :)

каких сервисов? web? так им пофиг оракл там или не оракл на другой стороне

(0) АЗС?

Oracle - это брэнд, а не продукт.
О чем речь?

по одбц можно данные оттуда тянуть

https://docs.oracle.com/html/E16659_03/xdb_web_services.htm

(0) у тебя должность какая? Почему надо что-то доказывать вместо того, чтобы предъявить требование: "интерграция со сторонними системами должна строиться на основе технологии SOAP-сервисов"?

Все эти одбц и прочие доисторические методы с файликами повышают связанность и взаимозависимость систем, что в итоге делает всю ИТ-инфраструктуру ненадежной и усложняет сопровождение. Вебсервисы отделают интерфейс от реализации, они не зависят от ОС, информационные системы ни чего друг о друге не знают и (что важно) ни каким образом не могут получить лишнего доступа, т.к. интерфейс умеет то и только то, что в него заложено и ни какими настройками прав или добавлениями объектов в метаданные случайно предоставить клиенту лишний доступ тупо невозможно. Можно долго перечислять на самом деле

Лефмихалыч хотел сказать, чем сложнее система (больше зоопарка), тем она надежнее. Слушайте Лефмихалыча!

>по одбц можно данные оттуда тянуть

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

(6) есть настраиваемая реализация SOAP для оракла?

(8) на оракле вполне можно настроить что больше чем нужно не увидишь

загоняй хранимыей процедуры в оракл и вызывай их через одбц и будет счастье без гемороя

(10) например создав вьюху

Это только в 1с принято, чутьчто сразу доступ через sa

(7) не вкладывай свои тупые мысли мне в голову

от тебя только одна задача, передать параметры и получить массив данных, а что да как пусть оракалисты репу чешут за свои мильоны.

(14) конструктивная критика всегда приветствуется.

(10) (12) (13) как в случае необходимость балансировать нагрузку от таких запросов?

(16) начни с себя

(17) Так бд заенимается балансировкой. А сервера приложений тут вовсе нет.
А нет нагрузки - нечего и балансировать

собственно дискуссию можно продолжать, но я для себя нашел волшебные слова "SOAP поверх HTTPS". А настройку Апача и прикручивание его к ораклу - оставлю ораклистам.

(19) почему соап, а на json?

(18) это - заплатка на плохую идею, т.к. масштабировать это тупо невозможно, поскольку клиент обязан знать, где конкретно лежит физическая СУБД.

(10) это в любой нормальной субд можно. только вопрос может стоять шире - никаких прямых доступов к базе. и все.

(20) "SOAP" замени на "web" и используй любой формат

+(21) а поменяется структура таблиц, тебе понадобится апдэйт ВСЕХ клиентов, т.к. в противном случае будет эпик фэйл. Вебсервис может и должен делать такие вещи незаметными для клиентов

(24) Про вьюху же речь идет

если веб-сервис накроется, то не будет работать ни один клиент - это надежность.
если накроется один клиент, то остальные будут работать, так как не связаны - это плохо и не надежно.

век живи - век учись!

(25) вьюха тоже может поменяться. Может потребоваться кэширование данных и тогда вьюха твоя совсем по звезде пойдет и опять перепИсь всех клиентов. С вебсервисом это все клиентов не затронет.

(26) этот риск не зависит от технологии - накрыться может что угодно. думай еще.

(27) так и вебсервис может поменяться

(28) вебсервис позволяет скрыть от клиента всю внутреннюю кухню. Вьюха - только запросы к актуальным таблицам БД. Сама БД и связанная с ней инфраструктура должны быть открыты клиенту.

>то я тоже буду нести такую пургу в массы?

в чем пурга то? никто никому уже давно прямого доступа к бд не дает

(30) вот это единственное преимущество.
А остальные пункты реализуемы и там и там

(31) отвечать на этот потёк сознания бессмысленно.

(32) так ради него вебсервисы и затевались. Это преимущество - это очень большое преимущество, когда мы говорим о промышленных системах, а не об на коленке хуяк-хуяк и в продакшн для трех клиентов

(12) +100
именно так лет 5 назад и делал интеграцию 1С с ораклом. проблем вообще никаких.

но задача была только в том, чтобы тянуть данные из оракла - в 1С и создавать или обновлять нужные объекты (и справочники и доки)

(34) По уму так и должно быть.
Но как зарядят ораклисты тыщ 300 за веб сервис. а за вьюху ..., да вьюху беспалтно 1с ник напиишет.
Тогда уже подругому подумаешь

(0) "хочу предложить им перейти на сервисы"
ответ ораклиста будет такой: "Сервисы? Ну делай как хочешь, хоть сервисы хоть ни сервисы.  Я тебе схему БД дал? Дал. Пока пока"

(36) ну, это совсем другой разговор, к теме не относящийся ни каким боком

(0) http://v8.1c.ru/o7/201312rest/ и пусть ораклоиды уже дальше сами

(39) я бы не стал. Мало ли что они там сами нахерачат. Сами-то в особенности. Это не сильно отличается от прямого коннекта к базе со всеми рисками-ирисками. Каждый должен заниматься своим делом - в 1с должен данные укладывать 1сник, в оракле - ораклист. Перемешивать одно с другим - плохая затея, т.к. можно пальцев недосчитаться по итогу.

(39) у меня задача оставить девственной базу 1с...

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

(41) Понял, у вас оракла а у клиентов 1С да еще и разные да?

Тогда однозначно сервис коннектящийся к ораклу поднимать. Причем заранее продумать этот сервис какой будет API для клиентов и как этот апи накладывается на базу оракла.
Предусмотреть возможность модификации/доработок апи, нумеровать их версии сразу и мануал с примерами обработко/кода на 1С для клиентов.

(42) *обработок

(5)+ http://www.oracle.com/technetwork/ru/middleware/webservices-manager/index.html

(41) Начиная с 8.3.9.1818 можно создавать Веб-сервисы в расширениях.

(41) тогда однозначно прямые коннекты к любой из сторон - путь в никуда.