не совсем понял замысловатый сленг, но то что предлагаемые спецификации не совсем массово применимы, согласен.

ДиезЕсли переводить SOA дословно, то получится всего-навсего "Архитектура, ориентированная на услуги " (а таинственные "сервисы" тут ни при чем).

Есть компании, предлагающие продукт, а есть компании, предлагающие услуги. И так будет и дальше. Так что SOA никуда не денется, просто займет свое место.
Таинственные "сервисы" здесь основное. Вы говорите о чем-то другом, типа SaaS, ASP, но явно не о SOA.

нужно уточнять о чем речь идет. Об архитектуре в приницпе или о конкретной реализации.

Vika Vinnerp7
одно из заблуждений, "вэб сервис" - один из способов реализации и не больше
Коллега - замечательно что Вы обратили на это внимание - Давайте порассуждаем о "не-вэб" реализациях SOA и посмотрим кому они будут нужны
Давайте, с точки зрения принципов SOA:
- функции приложений определены как сервисы. Сервисы могут представлять собой простые или сложные объекты, процессы, охватывающие некоторое множество объектов, которые в совокупности приводят к получению единого результата.
- Сервисы независимы друг от друга. Описание определяет суть сервиса, передаваемые ему параметры и получаемый результат. Сервисы выполняют определенные действия по запросам, полученным от пользователя или других сервисов, и возвращают результаты.
Основополагающим является интерфейс доступа к сервису. Сервисы имеют единый интерфейс для обращения к ним, независимо от реализации.
- Слабая связанность. Все сервисы связываются между собой только в момент их запуска, каждый из сервисов может работать абсолютно автономно.
Слабая связанность обеспечивает простую и быструю адаптацию системы в целом к изменениям в структуре и принципах реализации сервисов. Таким образом, обеспечивается гибкость, способность реагировать на изменения в бизнес-процессах динамично и без сложных трансформаций на интеграционном уровне, а также многократное использование создаваемых программных модулей.

почему, допустим, перечисленные выше характеристики не интересны за пределами "вэб"?

trdm_iscrafmпочему, допустим, перечисленные выше характеристики не интересны за пределами "вэб"?много хлопот, мало толку.
толк даже в перечисленных характеристиках. Для больших систем не порядок сокращает затраты и время. Все функции слабосвязаны, упрощенная компоновка, множественное использование, взаимозаменяемость. Вопрос только в том, как заметил Абдуллаh3, что "текущие реализации и обвязка - сложнее всего, до сих пор существовавшего". Но это больше проблемы реализации, чем архитектуры как таковой.

Vika VinnerДолжна быть единая стратегически разумная позиция всех поставщиков всех сервисов. А значит и единый протокол. Если Вы знаете что либо более универсальное чем вэб (& XML) на сегодня - я с удовольствием послушаю. .
согласен. А реализации действительно все идут по веб-дорожке.

trdm_iscrafmtrdm_iscrafmпочему, допустим, перечисленные выше характеристики не интересны за пределами "вэб"?много хлопот, мало толку.
толк даже в перечисленных характеристиках.
Это смотря кому их поддерживать, масштабу сервиса отклику сервера.
Лично для меня: "много хлопот, мало толку". Инфраструктура внутри предприятия связанная, данные тесно интегрированы - красота, обрабатывай и не жужжи.
если бы у меня каждый справочник был бы единым сервисом представлен, я бы повесился: было бы много дурной работы. SOA-подход он применим точечно. Как-бы там не хотели на нас подзаработать разные облачники для конечного спеца СОА-вешалка.
если каждый справочник представлен отдельным сервисом, то это только множество плюсов, а не "вешалка". Понадобилось его использование там, где изначально не планировалось - момент и он уже используется. Это только банальный пример справочника. А если более менее сложный документ в различных приложениях нужно использовать? 5 приложений и 5 платежек, в каждом своя. Вот что действительно "вешалка". Особенно если нужно внести изменение в бизнес-процесс проведения платежей.
А облачники здесь не причем, они такие же страдальцы, только облачные.

I l'v SOAiscrafmtrdm_iscrafmпочему, допустим, перечисленные выше характеристики не интересны за пределами "вэб"?много хлопот, мало толку.
толк даже в перечисленных характеристиках. Для больших систем не порядок сокращает затраты и время. Все функции слабосвязаны, упрощенная компоновка, множественное использование, взаимозаменяемость. Вопрос только в том, как заметил Абдуллаh3, что "текущие реализации и обвязка - сложнее всего, до сих пор существовавшего". Но это больше проблемы реализации, чем архитектуры как таковой.
Ерунда. Гораздо проще, чем DCOM&CORBA. Масса кодогенераторов, фреймворков, еtc, которые позволяют даже не задумываться о реализации.
и всю эту массу требуется заставить работать в унисон. Не так все просто. В веб-пространстве более продвинулись в этом вопросе, зачастую просто игнорируя предлагаемые "стандарты" и реализуя свое видение. В корпоративном секторе не так.

I l'v SOA
Не стоит обобщать, если Искра реализует свое видение и не придерживается стандартов, то это не значит, что все в корпоративном секторе поступают таким образом. А с стандартами все работает в унисон без всяких усилий на создание своих серверов.
я говорил не об Искре в принципе. Да, Искра для взаимодействия сервисов использует свой формат в рамках платформы. Т.е. "стандарты" (которые стандартами не являются, а являются де-факто и де-юре предложениями других поставщиков, правда с мировым именем, по организации SOA) в рамках платформы не задействованы именно в угоду простоте, скорости и минимизации затрат на разработку и поддержку приложений, но, конечно, с сохранением самих принципов SOA архитектуры. Дело там совсем не в формате обмена сообщениями. Мы наверное просто немного в разных величинах оцениваем усилия. То что Вы считаете "без услилий" не спеша для команды из n-человек за n-месяцев на проекте,возможно, я просто считаю расточительством полученного за реализацию проекта денежного вознаграждения.
А речь шла о том, что в корпоративном секторе большая доля легаси-приложений, которые понятия не имеют о сервисах и архитектуре SOA в принципе.

I i'v SOA
Возможно, раньше Искра давала выигрыш в разработке, но не сейчас. Помимо этого есть еще дальнейшее сопровождение и развитие системы. С общими форматами обмена сообщений и поддержкой ведущих вендоров вероятность не зря потраченных денег гораздо выше.
немного не понял года раньше и что изменилось?

iscrafmI i'v SOA
Возможно, раньше Искра давала выигрыш в разработке, но не сейчас. Помимо этого есть еще дальнейшее сопровождение и развитие системы. С общими форматами обмена сообщений и поддержкой ведущих вендоров вероятность не зря потраченных денег гораздо выше.
немного не понял года раньше и что изменилось?
года = когда

I i'v SOA Сводки с полей корпоративного сектора
как это к SOA относится?

Petro123а SOA именно лоскутная и есть...
немного некорректно. Лоскутная - это несвязанная. в SOA сервисы связанны, хотя по определению могут работать и автономно. Просто, в отличие от "монолита", SOA система построена из низки функций (сервисов), которые общаются по определенному протоколу и компонуются в единое целое.

I l'v SOAiscrafm
как это к SOA относится?

Самым непосредственным образом. Облака - одни сплошные сервисы без необходимости своего натурального хозяйства. Возможность простого развертывания своих сервисов, БД, файловой системы, Service bus, Message Bus, стандартные протоколы и тд, что еще нужно для компоновки в единое целое? Пока нет распределенных запросов и транзакции, но будут.
Понятно. О этой ошибке сказали еще в начале топика, непонимание что такое SOA. Все смешалось в кучу ASP, SaaS, SaaP и прочее. И почему то SOA. Сервисы, да не те.

p.s. Так что с Искрой случилось? Так и не ответили...

Petro123iscrafmPetro123а SOA именно лоскутная и есть...
немного некорректно. Лоскутная - это несвязанная. в SOA сервисы связанны, хотя по определению могут работать и автономно. Просто, в отличие от "монолита", SOA система построена из низки функций (сервисов), которые общаются по определенному протоколу и компонуются в единое целое.
мы просто путаем цели.
"Лоскутная" это более широкое понятие.
Мы оцениваем технологию с точки зрения архитектора-разработчика .
Что он выигрывает:
- если вместо хорошо управляемых объектов "Справочник_с_бизнес_логикой" с хорошо зарекомендовавшими событийными и транзакционными механизмами он получит ПЛОХО управляемый сервис?

Это и есть плохо управляемые "лоскутки", которые надо собрать в одно целое (нанять оркестровку веб-сервисов :) )
я, к примеру, получаю прекрасно управляемые и не лоскутки. Правда веб-вервисами не дирижирую. Сама архитектура SOA не предусматривает плохо связанную конструкцию, т.е слабо-связанный <> плохо связанный . Слабосвзянный - это стыковка в момент исполнения, многократное использование, взаимозаменяемость. Т.е. характеристики, которые на порядок упрощают разработку и управление жизненным циклом продукта. Но никак не плохая управляемость.

I l'v SOA
C точки зрения архитектора-разработчика он получит внятную систему c четким разделением, масштабированием и прочими радостями, а не одно большое одеяло, которое ПЛОХО поддается перекройке
+1

Petro123iscrafm,
то же самое говорили про COM, как панацею.
Автор топика (как и я) взглянул шире, про тенденции
разговор про панацею не ведется. Нить топика натянулась в сторону реализаций, а не архитектуры как таковой. А у архитектуры принципы простые, некоторые из них, чуть выше перевел.

trdm_
ИТ-шник на предприятии может влегкую решать текущие поставленные задачи при наличии инструментов, при использовании SOA - это невозможно.
По этому ИТ-шники не особо приветствуют этот статические плохо приспособленный к изменениям булыжник.
читаешь иногда и думаешь: почему те, кто тебя не знает, так уверенно пишут что ты не ешь мясо. Спектакль абсурда. Легко решаются задачи, хорошо приспособленная именно к изменения в том числе архитектура. Может это сон? Или рассуждения о вкусе устриц людей, никогда их не пробовавших? Скорее второе.