web_foxiscrafmСлабосвзянный - это стыковка в момент исполнения, многократное использование, взаимозаменяемость. Т.е. характеристики, которые на порядок упрощают разработку и управление жизненным циклом продукта. Но никак не плохая управляемость.

многократное использование сервисов - по-моему, миф. В вашей SOA сколько сервисов и сколько из них повторно использованы?

PS. Я не против SOA. Просто заметка.
смотря в какой из систем. Под рукой что есть глянул, чуть более 600. Повторно используется многие конечно.

trdm_опять искроскрины. а на них у меня алергия уже.

когда будут обсуждаться вопросы, к которым Искра не имеет отношения, скринов не будет.

p.s. Попей лоратадина, помогает.

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

а можно пример такой транзакции?

немного о примерах таких транзакций...

1. Распределенная система визирования документа. Для подписей используется сервис, который в случае отказа принимающей стороны ставит конверт с подписью в очередь ожидания. Выполнится в любом случае, с задержкой.
2. Сервис записи проводок по документа в момент его учета во внешнюю бух.систему. Такая же ситуация.
3..

_мод
Простой пример: провели документ, надо экспортировать проводки во внешнюю систему.
вариант 1 - дернуть сервис, который не известно как завершится
вариант 2 - прямой доступ к внешней БД с полным контролем над завершением
и что выберем ?
вариант 3: сервис, который обеспечивает прямой доступ к БД, если к ней возможен доступ. Опять же вариант с проводками не очень показательный. Это тоже пример сервиса, который может быть выполнен даже со значительным таймаутом.