iscrafmweb_foxНапишите, пожалуйста, подробнее: на какой платформе вы построили SOA, примерно сколько сервисов в % повторно используется. Сколько % сервисов работает на запись бизнес-данных (логирования не в счёт). И, если можно, как происходит решение, что сделать сервисом, а что не стоит (что ограничивает).
Вы же понимаете, что мне легче не рушить Ваши заблуждения, чем считать проценты . На запись бизнес-данных работает подавляющее большинство (а на что еще работают сервисы в бизнес-приложениях?), в процентах не считал. Повторно используется масса. Решение, что сделать сервисом пришло единоразово - все . Любая функция, будь то функция для ввода данных, их обработки или анализа, в SOA архитектуре, есть сервис, посаженный на общую шину. Но судя по Вашим вопросам и вопросам, поднятым чуть выше, кроме варианта реализации SOA в форме веб-сервисов ничего больше не рассматривается. А как же ESB, серверы приложений...? Поэтому и странно звучат вопросы по, казалось бы, банальным вещам в разработке - многократное использование.

Такое ощущение, что вы вошли в кураж, споря в этой теме. Я про веб-сервисы вам ничего не писал, может вы спутали что-то. Я без стёба ставлю реальные вопросы, которые лично меня интересуют.

>Более того, ничего странного и банального. В практике просто не припомню чтобы что-то повторно использовалось (может для вас это и удивительно), поэтому мне интересна была ваша статистика. Даже в обычном программировании повторно используются только какие-то классы системного характера. Например, в БД к повторному использованию годились только представления, функции повторно использоваться могут, но это малая часть. Под каждую задачу всегда нужны сугубо конкретные данные и делать выбор всех данных, чтобы кто-то использовал только часть не имеет смысла. Это в моей практике. Я ни о чём с вами не спорю.

Вот мне интересно, поэтому прошу, приведите, пожалуйста, показательный пример из вашей практики, где сервис повторно используется разными потребителями, насколько одинаковый набор данных они читают или пишут. (Например, есть сервис А для системы Альфа, закрывающий/открывающий клиенту интернет. Он используетя тремя системами: биллинговой в случае превышения денежного лимита, системой Бетта в случае..., и т.д. Чем подробнее, тем лучше).

И интересует на какой платформе вы сделали SOA?

_модНе ИСКРАЛюбое решение имеет свои достоинства, недостатки. Особенно в краиних и криминальных вариантах. Огласите в процентах кол-во ваших распределенных транзакций.
Достаточно одной. Но вообще внешних связей всегда много.
Простой пример: провели документ, надо экспортировать проводки во внешнюю систему.
вариант 1 - дернуть сервис, который не известно как завершится
вариант 2 - прямой доступ к внешней БД с полным контролем над завершением
и что выберем ?

Вы правильно поняли слабое место этих систем в текущей реализации. Гораздо проще и надёжнее общаться на уровне баз данных через дблинки - базы разных систем, но транзакция одна. Можете об этом дальше не спорить )

Откуда появляется желание использовать SOA... оттуда, что возможно построить построить архитектуру звезды, а не точка-точка при интеграции систем. Количество связей точка-точка постоянно растёт и управление ими начинает происходить в режиме пожар-тушение. При использовании платформ идеологии SOA (при удачном подходе к барьеру) можно автоматизировать как транспортную функцию (единый репозиторий интерфейсов, гарантированная доставка, мониторинг нагрузки, сбои и т.п.), так и управление бизнес-процесом (ветвление, интерфейсы пользователя, и т.п.). Это (при удачном подходе к барьеру :) позволит избавится от детских болезней на предприятии с большим числом ИС и связей. Ну и совсем уже мечта владельцу бизнеса сидеть и смотреть в графическом представлении, какие бизнес-процессы крутятся в системе и какова по ним частота прохода.

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

_модweb_foxОткуда появляется желание использовать SOA...
Единственный смысл сервисов - это изменение парадигмы. Сейчас задача сама решает, какой сервис использовать. А надо наоборот, ставить задачу и ее будет решать самый подходящий для нее сервис.

Вы правы. Но вы уже захватываете гораздо более широкую проблемную область, чем здесь обсуждали ;) Тут о более призёмленных вещах пока разговор - что-то типа о "поменьше программируйте - побольше мышкой кубики складывайте".

_модweb_foxОткуда появляется желание использовать SOA...
Единственный смысл сервисов - это изменение парадигмы. Сейчас задача сама решает, какой сервис использовать. А надо наоборот, ставить задачу и ее будет решать самый подходящий для нее сервис.

Если я не ошибаюсь, с таким подходом речь о платформах пока не идёт. Зато уже есть языки программирования, которые поддерживают такой подход: F#, objective C и др.