Я написал некоторые размышления в своем блоге, но подумал, что это достойно публикации и на форуме тоже. 
Оригинал тут - о SOA, о SOA, о SOA - о !!!

Несколько лет назад я читал японское хокку, посвященное какому-то необычайно красивому месту в Японии. Названия не помню, но если предположить, что это название Фудзияма (как наиболее известное, да и по количеству слогов подходит), то звучать оно будет так:

О, Фудзияма,
О, Фудзияма,
О, Фудзиямя,
О

В смысле, что передать словами восторг и восхищение данным местом невозможно.

Когда я слышу излияния современных менеджеров от IBM и Oracle, которые продают уже "готовые" решения для SOA (кто не знает - Service Oriented Architecture), то у меня возникает ассоциация именно с этим хокку. Т.е. все восхищаются, но вот понять как этим воспользоваться - не получается. Вот так и стоим в восхищении.

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

Идея SOA достаточно проста и понятна - все предприятие с точки зрения IT организуется как система сервисов, которыми можно пользоваться. А управлять этими cервисами будут бизнес-процессы, которые опишут менеджеры, красиво их нарисуют в какой-нибудь программе и дадут программистам, чтобы те реализовали конечные сервисы. Причем реализации логики вызова этих сервисов уже не головная боль программистов. 
Вообщем мысль очевидная - если существуют уже готовые сервисы в рамках предприятия, то управление предприятием может использовать эти сервисы по своему усмотрению, определять правила перемещения информации от сервиса к сервису. Если сервиса не хватает - пишем новый. Хорошо бы увидеть возможность делать это в рамках одной транзакции - но вот производители пока умалчивают о такой возможности. Я пока такое не видел. Ну да ладно. Вообщем - если существует такая инфраструктура, то теперь жизнь предприятия станет сказкой.

Дело за малым - описать бизнес в виде бизнес процессов, определить какого рода ресурсы и сервисы требуются для этого, определить правила мониторинга и управления. И вот тут возникает пауза - кроме "О" ничего в голову не приходит.
На днях столкнулся с книжкой "The New Langauge of Business. SOA and Web 2.0" Sandy Carter (Vice President, SOA and WebSphere Strategy) - оказывается IBM разработала системы построения бизнеса аж для 69 типов предприятий различных индустрий. Так все уже придумано - берем необходимый вариант организации, подправляем и вперед. К новым горзонтам. 

Так и представляю себе, как менеджеры среднего и высшего звена сидять перед компютерами и вдохновенно определяют - как же построить этот бизнес-процесс закупки или оплаты или принятия решения о кредитовании важного клиента. Ну для тех, кто повыше - они будут рисовать диаграммы построения трендов продаж и стратегические сервисные службы для поддержания командного духа. Не улыбнуло еще ? Интересно, когда менеджерам будут предъявляться требования знать например Business Modeler при приеме на работу ? А к нему еще Process Server. Это я о продуктах IBM - я их знаю немного. Кстати, они действительно позволяют все это красиво рисовать, и это даже как-то работает. Правда есть несколько моментов. 
Во-первых, это жутко сырые продукты - но тут дело времени. В итоге устоятся и будут работать более-менее надежно. Но есть второй момент - эти продукты не так уж просты в изучении. И на сегодня для их изучения навыки программирования мне помогают очень. В противном случае - полное непонимание. А тут предлагается менеджеру этим заниматься ? Да не будет он. И наверно он прав. На листочке, в общих чертах - пожалуста. Возможно даже докладная записка будет написана. Но переводить это все под ESB будете вы - программисты.
А тогда толк какой ? Я и без ESB могу прекрасно интегрировать необходимые службы - и раньше мог. RPC, DCOM, RMI, WebServices еще никто не отменял. Создал новую форму с данными, нарисовал кнопку - а на нее обработчик, в котором вызываем в нужной последовательности нужные нам сервисы. Тот же сервлет прекрасно сможет выполнит все необходимое. Причем если посмотреть на возможности выражать логику у того же Business Modeler - да мне быстрее написать десяток IF, CASE и тому подобное, чем изучать и мучаться с этим картинками, стрелками и прочая. В конце концов тот же UML позволяет генерить код ничем не хуже.

Но хватит критики - теперь можно поговорить и о положительных сторонах. SOA позволяет взглянуть менеджерам на свой бизнес по-другому. И в этом уже есть огромный положительный момент. То, о чем программисты и системные аналитики твердят постоянно, теперь озаботит менеджера. И возможно он увидит, что бизнес надо организовать по понятным правилам. Кроме того - уже есть стандарт описания бизнес процессов и системы выполнения этих описаний. BPEL называется.

Как я вижу востребованную реализацию SOA ? Это должна быть уже готовая система, которая на вход получает описание бизнес-процесса с необходимыми вкраплениями тех сервисов, которые будут задействованы в нем и описанием данных, которые будут передаваться внутри этого бизнес-процесса.
А для этого надо. чтобы выполнялись следующие требования:
- Бизнес-процесс должно быть удобно описывать. Что вообщем пока не выполняется. Хотя если потратить на изучение BusinessModeler'а месяц, то наверно можно. Но не уверен.
- Достаточно прозрачная интеграции приложений с ESB. Чтобы вопросы "как начать весь процесс", "как передать начальные данные", "как сделать остановку бизнес-процесса для того, чтобы менеджер нажал кнопку на Web-интерфейсе" не вызывали больших проблем.
- Наконец самое главное - чтобы менеджеры хотели этим заниматься. На сегодня им проще описать словами. что надо. В крайнем случае написать это в текстовом документе.

И вот тогда SOA сможет занять место в нашей жизни. Но пока это больше абстрактные рассуждения и маркетинговые ходы - на мой взгляд. Спасибо за внимание.

Антон, про менеджеров понятно. Но кроме них и разработчиков во многих конторах есть ещё и аналитЕГИ. Не знаю, как продукты IBM, но продукты бывшей BEA (теперь - подразделения Oracle) позиционируются, насколько я понимаю, как продукты для системных и бизнес-аналитиков, которые смогут теперь от косвенного участия в разработке информационных систем (посредством документации и обсуждения с разработчиками) перейти к непосредственному участию в разработке, рисуя в специальных инструментальных средствах (в нашем случае - BEA Aqualogic BPM Designer) диаграммки на BPEL или XPDL, которые будут экспортироваться в среду для разработчиков (BEA Aqualogic Studio) и уже там остальное будет дописываться разработчиками.

Многие аналитеги в среднем, мне кажется, на такой подвиг способны, в отличие от менеджеров. А про менеджеров я согласен 

Аналитик - специально подготовленный человек, который мог бы для программистов и так написать, все что им надо.
Т.е. вопрос заключается вот в чем - насколько эффективнее этот business-process engine сможет реализовывать логику, чем простой последовательный вызов сервисов (по нужной логике) из какого-то бина под AppServer'ом.

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

Думаю, что тут может возникнуть проблема "кажущейся простоты" - я так называю возможность легко код приложения, что порождает всегда массу проблем, типа "а давайте теперь сделаем иначе". Когда архитектура уже заточена, то переделать такое сложно - да ты сам прекрасно это знаешь.
Т.е. впечатление, что теперь можно менять бизнес-процессы одним движением волшебной палочки может завести в сложные дебри поддержки целостности работы системы. Причем тут система будет огромная. А значит и последствия могут быть ого-го.

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

А ведь наверно самое интересное и самое мощное, что есть в SOA - подключение сервисов к шине и ENGINE для бизнес-процессов. Вместе это действительно выглядит многообещающе.

Речь идет о стихотворении Басё про Мацусиму "О Мацусима" - одно из трех самых красивых мест Японии. Сейчас - одно из самых засраных туристами мест Японии

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

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

Я на них гляжу с подозрением.
Надо очень хорошо прочувствовать и потом уже юзать.

Пока что это хорошо для больших корпораций, которые готовы большое бабло выкладывать за "прогрессивное" но не за "полезное".
Особыъ преимуществ не вижу пока. РЕАЛЬНЫХ.

Сразу вспоминается "мне надо сделать для маленького магазина простой тупой каталог товаров. Как правильно заюзать еджиби, вебсервисы, стоит ли юзать хибернейт, пригодится ли мне тут кластер и что это такое, думаю использовать вебсферу и оракл".

Как показывает грёбаный опыт - вместо ручной работы по написанию каких-то фишек часто приходится брать "уже написанный"(с) раскрученный промышленный перфоратор и пытаться его использовать вместо цыганской иголки при штопаньи тапка.
Зато круто. "Я знаю карате, ушу, кунг-фу и ещё много страшных слов"(с). Один из основных приципов создания нынешних аппликейшнов )

Я вот просто думаю - насколько быстрее будет делать наброски в спец тулзах специально подготовленному аналитику... Увеличится ли скорость итоговая существенно? А если неподготовленные? Ммм...

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