ROI от SOA – хочется больше?

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/13/ROI-_3E044204_-SOA-_1320_-_45043E0447043504420441044F04_-_31043E043B044C04480435043F00_.aspx

В августе Nucleus Research опубликовала результаты опроса компаний, применивших методологии SOA во внутрикорпоративных разработках. Исследование очень интересное, и я вкратце решил пересказать те результаты, которые они опубликовали в открытую. На западе оно наделало много шума – в основном на волне критике SOA (теперь это стало модно), хотя, на мой взгляд, оно очень даже позитивное.

Итак:
1) Только 37% компаний достигают положительного ROI от вложений в SOA.
2) SOA увеличивает продуктивность разработчиков, но обычно все ограничивается только 1 проектом на уровне департамента, что уменьшает возврат инвестиций.
3) Только 40% разработчиков использует SOA
4) Те разработчики, кто использует SOA повышают продуктивность на 28%.
5) Больше всего SOA используется в здравоохранении (62% power пользователей против 48% в material companies);

Выявленные проблемы:

• разработчики считают себя творцами кода и не хотят повторно использовать чужие наработки, и поэтому сторонятся SOA;


• для успеха необходимо интенсивнее вкладываться в обучение SOA, нежели делается;


• размер SOA зависит от числа опубликованных в реестре сервисов, но инструменты для реестров дороги и компании их не покупают.

PS. Я бы добавил, что когда программисты просекут, что SOA в конечном итоге делается, чтобы не "плясять" перед ними по каждому пустяку, то они совсем откажутся работать в SOA-проектах. :))

Publised 13 сентября 2007 г. 16:26 by Vlad Borkus Edit
Filed under: SOA

Моя презентация про SOA на конференции «Ассоциации ДокументальнойЭлектросвязи» (repost)

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/12/54191.aspx

Выложил на наш сайт слайды своего выступления об SOA на конференции Ассоциации Документальной Электросвязи, состоявшейся в 12 сентября. Ввиду специфики мероприятия, я попытался объяснить структуру SOA что называется «на пальцах», т. е. дать максимально упрощенное представление.

Так как планировалось делать выступление в компании мировых лидеров (Sun, IBM, Oracle), то надо было придумать «фишку» -- таковой я выбрал тему анархии и порядка в ИТ, и SOA как один из методов для их балансирования.

Хотя я считаю презентацию удачной, но, судя по вопросам из зала, некоторые моменты все же недоработал (например, как делать SOA инкрементально, или детали того, как выделять сервисы, чтобы они были повторно используемые, недоговорил про сложности и недостатки) – жду пощады от критиков.

PS.

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

Но за день до конференции выяснилось, что нужно не просто «поболтать», а сделать доклад, причем на 10 минут (длительность, что называется "ни туда, ни сюда") – и пришлось в срочном порядке рисовать слайды.

Потом новая беда – на лидеров рынка нашла «черная полоса»: у одного потеряли билеты, которые надо было сдавать в посольство, другой застрял в пробке, а еще пара людей не явилась без видимых причин. Из лидеров выжил только IBM (конечно, Gartner это предсказывал давно, но не в данном контексте :) ))

По итогам – на КОННАСИ (т. е. меня) и IBM распределилось в сумме 1,5 часа вместо запланированных 10+10 минут . Я выступал первым – пришлось принимать на себя большую часть ударов с критикой SOA.

Презентация «SOA: баланс между анархией и порядком для развития ИТ»

В формате PDF:


И для порядка:

Презентация по перспективам SOA в России, сделанная в июне на конференции TIBCO:

В формате PDF:



Статья в PCWeek/RE с трезвым взглядом на SOA («Практическое построение SOA: борьба с мифами»):

В формате PDF:


//Влад Боркус

Published 12 сентября 2007 г. 12:25 by Vlad Borkus
Filed under: SOA

BEA купят, а жаль

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/10/bea.aspx

eWeek сообщил на днях о единодушной уверенности всех западных аналитиков в том, что в ближайшие полгода состоится покупка BEA каким-нибудь из крупных вендоров. Причины – у компании не ладится бизнес в северной Америке и она не добирает оборотов относительно прогнозов. В первом квартале прогнозировали $358, получили -- $342. Акции упали, соответственно с $16 до $11.

Основных покупателей два: Oracle и Hewlett-Packard. Руководство Oracle не скрывает, что хочет сделать это приобретение, но просто ждет подходящего момента. HP тоже в покупке заинтересовано, но у нее хуже с деньгами – она не может выплатить такую же премию за акции, как Oracle. (См. http://www.eweek.com/print_article2/0,1217,a=213246,00.asp)

Мне, как аналитику в этой области, искренне жаль. Программный комплекс BEA был построен очень грамотно и качественно. Вряд ли наиболее вероятный покупатель (Oracle) сохранит платформы WebLogic и AquaLogic как они есть. Middleware – не ERP, и ситуация с PeopleSoft вряд ли повторится. Скорее всего будет взят курс либо на полную ликвидацию этого ПО, либо на его унификацию с аналогичными линейками Oracle (SOA Suite, BPM Suite), возможно с сохранением лишь отдельных продуктов.

Как бы то ни было, но ухудшение состояния BEA указывает на изменение спроса на рынке middleware, где все меньше возможностей остается для независимых поставщиков «тяжелых» платформ.

//Влад Боркус

Published 10 сентября 2007 г. 13:28 by Vlad Borkus
Filed under: SOA

Comments

IBM: ESB мешает SOA

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/03/ibm-esb-soa.aspx

Несколько лет, когда технология ESB (Enterprise Services Bus) была «коньком» фирмы Sonic Software, корпорация IBM ее недолюбливала. Но потом, когда ESB была разрекламирована Garnter, то IBM резко сменила позицию и выпустила свой ESB-продукт. Но вот недавно на сайте DeveloperWorks появилась статья о том, что увлечение ESB мешает правильному пониманию концепций SOA, подменяя внедрение архитектуры внедрением программного продукта. (http://www.ibm.com/developerworks/webservices/library/ws-soa-esbarch/index.html)

Многие блоггеры восприняли статью как знак того, что IBM «сдает» ESB, хотя внимательное чтение показывает, что это не так. Скорее IBM подводит читателя к мысли, что помимо покупки ESB стоило бы приобрести и консалтинг в области SOA.

Главных тезисов по ESB и SOA всего два:

• внедрение ESB-ориентирвоанной архитектуры само по себе не дает добавочной бизнес-стоимости, так как это чисто технологическое решение для соединения сервисов;
  
• в отличие от ESB главная цель SOA – это согласование бизнес-мира и мира ИТ, а потому несет четкую бизнес-ценность.
  

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

Вместе с тем статья содержит еще пару полезных соображений по философии построения софта, которые, на мой взгляд, стоит помнить, но часто забывают:

• Не создавать системы «на будущее».
  
• Внедрять только то, что уже нужно бизнесу;
• Стыковать потребности бизнеса и ИТ-решение.
  

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

Published 3 сентября 2007 г. 0:01 by Vlad Borkus
Filed under: SOA, ESB

WS-Security: начинание благое, но безопасность SOA не обеспечивает

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/08/19/ws-security.aspx

Одно из основных правил программирования говорит о том, что специализированное решение в своей узкой области как правило будет лучше обобщенного. Это свойство всегда проявляется при выработке стандартов – в них закладывается либо самая общая, либо «усредненная» модель. В первом случае стандарт получается очень сложным, во втором – открывается поле для всевозможных фирменных расширений, его «улучшающих».

Примерно так обстоит дело со стандартами в области безопасности SOA. В стеке WS-* запланирована очень глобальная модель безопасности, включающая почти десяток всяких спецификаций (WS-Security, WS-Secure Conversation, WS-Trust, WS-Federation, WS-Policy, а также XML Digital Signature, Security Tokens Profiles (для SAML, Kerberos,X.509) и т. п.

Благодаря этому возникает целый комплекс очевидных проблем для SOA:
1) Не все эти стандарты реализованы одинаково во всех продуктах, что делает разные компоненты SOA несовместимыми.
2) Так как общие стандарты разрабатываются медленно, открывается поле для "частных" расширений вендоров, которые еще более снижают совместимость.

Я бы не стал писать про это статью, но на днях натолкнулся на интересное выступление на эту тему специалиста в области безопасности Брэда Хилла (http://www.isecpartners.com/files/iSEC_HILL_AttackingXMLSecurity_bh07.pdf). В почти 200-страничной презентации обстоятельно показывается, почему стек WS-S -- пока не лучший способ для обеспечения безопасности для открытых в Интернете сервисов,B2B-сервисов и внутрикорпоративных web-сервисов.

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

Но для этих задач ЛУЧШЕ всего подходит стандартный SSL, при одновременном применении _клиентского_ и северного сертификатов. В самом деле, у него есть набор явных преимуществ:

1) Он решает как задачу безопасной аутентификации (по сертификату);
2) Он защищает трафик от пользователя к системе;
3) Что еще более важно -- он совершенно ОДИНАКОВО реализован во всех системах, в том числе старых -- пяти и даже более летней давности;
4) Он покрывает 99% процентов того, что нужно для решения реальных задач.

Модель же безопасности на уровне сообщений, примененная в WS-S, не дает в этом смысле никаких преимуществ, так как опять-таки в 99% случая все, что от нее требуется -- это аутентификация пользователей. Но он также неодинаково реализован на новых и старых системах, а применение агентов-посредников тоже не всегда удобно и эффективно. Также WS-S (в конечном итоге за счет XML Digital Signature) опирается на шифрование больших объемов данных открытыми ключами – очень ресурсоемкая операция по сравнению с симметричным шифрованием в SSL. Поэтому при использовании для интеграции внутрикорпоративных систем WS-Security оказывается менее адекватен, чем SSL.

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

WS-Security плох тем, что для его реализации используется работа многих слоев (от XML Encryption, XML Digital Signature, Security Tokens Profiles (SAML, Kerberos, X.509), WS-Trust, WS-Federation и т.п) -- слишком много точек для потенциальной атаки, слишком сложно заставить все это скоординировано работать.

Брэд Хилл показывает в своей презентации как можно эти уязвимости использовать, какие есть стандартные "дыры" в реализации этих спецификаций, например, в XML Парсере. Эти дыры можно было бы отключить настройками, но сегодняшние продукты таких настроек не предоставляют. И в любом случае получается слишком много предположений о квалификации среднего корпоративного разработчика.

Вместе с тем, стек WS-S создает ряд бизнес-возможностей, таких, как цифровые деньги, DRM-применения, распределенная аутентификация, и транзакции, в которых участвуют много сторон. Но так как последствия для безопасности от самостоятельного использования этих протоколов пока до конца не изучены, то WS-S рекомендуется применять не самостоятельно, а вместе с отлаженной базой SSL.

//Влад Боркус, www.konnasi.ru

Published 19 августа 2007 г. 23:09 by Vlad Borkus Edit
Filed under: SOA, Безопасность

Comments

Новый арсенал "серебрянных пуль"

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/07/09/18921.aspx

Прочитал недавно очередной прогноз, касающийся SOA. В общем, все как обычно, но несколько положений заинтересовало. В частности, в нем говорится, что в ближайшее время вендоры перестанут пиарить аббревиатуру SOA, а переключатся на рекламу EDA. Так как подобное вполне возможно (нужна новая «серебрянная пуля»), то можно поговорить немного об этом «новом прорыве» и о некоторых других.

EDA расшифровывается как Event Driven Architecture, т.е. архитектура, построенная на обработке событий. События рождаются в одних системах, попадают на шину доставки и потребляются другими системами. Получается, что EDA -- это наследница технологий MOM (Message Oriented Middleware). Собственно, и программное обеспечение, через которое распространяются события EDA -- это, как правило, шина на базе JMS (Java Messaging Service), т.е. самый что ни на есть MOM.

Есть в EDA, правда, и некоторые добавочные вещи, например, повсеместность событий (сервисы могут генерировать события), возможность по событию инициировать вызов сервиса (т.е. синхронной коммуникации) или запуск делового процесса, возможность мониторинга событий (в том числе через агрегаторы типа dashboards), средства интеллектуальной корреляции событий (Complex Event Processing (CEP).

Например, BPM-система TIBCO iProcess Suite может автоматически генерировать события по завершению каждого шага делового процесса. Другие инструменты TIBCO могут находить соответствия в цепочках событий, и, например, создавать новое событие, которое запускает деловой процесс. (Аналогичные возможность есть в ПО Oracle и других.). И все же сказать, что EDA -- вещь абсолютно новая, сложно.

Для привязки вызовов сервисов к событиям одной MOM уже мало, нужны средства ESB (Enterprise Services Bus). Продукты ESB (Enterprise Service Bus) и дополнительные к ним модули основных производителей -- BEA, Fiorano, IBM, Oracle, Sonic, TIBCO -- поддерживает EDA «из коробки». Но среди вендоров пока нет терминологического согласия на тему, является ли EDA частью SOA или нет. Например, TIBCO считает, что является, а Oracle, что это уже «больше, чем SOA».

Есть еще один набирающий популярность термин/набор стандартов -- SCA (Service Component Architecture, архитектура служебных/сервисных компонент). Суть здесь состоит в создании сборок сервисов, описания интерфейсов которых отделены от инфраструктурной составляющей.

В системе выделяются компоненты, решающие какие-либо бизнес задачи, и для каждой из них задается интерфейс внешнего доступа в виде группы сервисов. Изменить данные в компоненте можно только через эти сервисы. Сами сервисы и компоненты описываются терминах именно бизнеса, а не технологий. Иначе говоря, если в SOA (по мнению некоторых) может фигурировать "сервис обновления таблицы БД", то в рамках SCA может быть исключительно сервис «обновить данные о клиенте» в объекте «клиент».

Существенно, что такую компоненту/интерфейс потом можно при помощи деклараций привязывать к конкретному технологии -- Java, COBOL, PHP, XML-языки (BPEL) и т.п. В ходе жизненного цикла, можно менять технологический слой компоненты, не трогая интерфейс. SCA индифферентна к тому используются ли синхронные или асинхронные вызовы, а обращающиеся к компоненте системы в технологическом плане могут быть оформлены весьма различно.

Подобная «высокоуровневая» объектная ориентированность позволяет разработчику компоненты инкапсулировать в ее описании все зависимости данного сервиса от других сервисов. В итоге упрощается применение в сервисам политик доступа, политик доставки, обеспечение транзакционности -- они задаются декларативно на уровне SCA, а не в рамках программного кода. Также управлять жизненным циклом компонент проще, чем жизненным циклом «кучи» сервисов. В общем, новое есть. Некоторые называют все это «SOA NextGeneration/2.0», хотя, наверное, это чересчур оптимистично.

PS. Замечу, что SCA также опирается на технологию SDO (Service Data Objects, служебные объекты данных) для передачи параметров и возвращаемых значений. Это инструмент для универсального описания объектов данных (в терминах графов) и интерфейсы для манипулирования ими.
PPS. В настоящее время SCA поддерживают продукты BEA, IBM, Oracle, TIBCO и несколько более мелких вендоров. Работы по SCA ведутся в рамках проекта «открытая SOA» (www.osoa.org)
//Влад Боркус, www.konnasi.ru
Published 9 июля 2007 г. 16:08 by Vlad Borkus Edit
Filed under: SOA

Comments

Отчет о перспективах технологии SOA и BPM в России на конференции TIBCOSoftware

27.06.2007 Выступил на конференции Welcome Event, посвященном представлению компании TIBCO Software (www.tibco.com) с докладом о состоянии и перспективах методологии построения композитных приложений SOA (Service Oriented Architecture) и технологии управления бизнес-процессами BPM (Business Process Management) в России.

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

Так, на российском рынке можно найти практически любые программные продукты для построения SOA, а также экспертизу по их использованию. Хотя законченных масштабных проектов построения сервисно-ориентированного ИТ-пространства на сегодня в России нет, тем не менее имеются проекты внедрения технологий, связанных с идеями сервисной ориентации, таких, как корпоративные шины сервисов ESB (Enterprise Services Bus). Ряд отечественных подрядчиков имеет опыт интеграционных проектов с применение систем Enterprise Applications Integration (EAI) и Message Oriented Middleware (MOM), и постепенно набирает экспертизу в SOA. На рынке также присутствуют западные вендоры и консалтинговые компании, имеющие опробованные методологии развертывания SOA.

Сложнее обстоит дело с готовностью самих заказчиков к SOA. Глубинные предпосылки для SOA имеются в настоящий момент только в финансовой и телекоммуникационной отраслях. Здесь скорость реагирования ИТ на изменения бизнес-среды напрямую влияет на результаты работы компании, а SOA обещает именно такую гибкость. Отрасли также находятся в состоянии роста, идут процессы укрупнения фирм и реструктуризации, роста парка ИТ-систем. Дополнительными стимулами является необходимость осуществлять интеграцию с внешними организациями (например, в банковской отрасли), потребность улучшения деловых процессов, создания новых услуг.

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

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

Подробнее материалы доклада можно найти по ссылке.

О треугольнике "SOA, бизнес, ИТ"

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/05/23/_1E04_-_420440043504430433043E043B044C043D0438043A043504_-_2200_SOA_2C00_-_3104380437043D04350441042C00_-_180422042200_.aspx

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

1) Бизнес готов ставить перед ИТ-службой задачи на понятном ему, бизнесу языке. И эти  задачи часто меняются. И бизнес ожидает, что ИТ будет на них оперативно реагировать. Но при выполнении этих задач у ИТ возникают технические сугубо ИТ-проблемы, а объяснить их он бизнесу не может --  эта предметная область для _большей части_ бизнес-руководителей чужда.

2) Поэтому задача ИТ-директора -- найти инструмент, чтобы быстро выполнять новые «хотелки» бизнеса, а может даже предлагать бизнесу еще какие-то новые идеи, которые можно будет быстро и дешево реализовать средствами ИТ, и которые будут иметь полезный коммерческий эффект.

3) Вендоры пытаются такой инструмент предложить в виде концепции SOA и ряда технологий. Объяснить, что такое SOA бизнесу невозможно -- я совершенно согласен с Павлом Эйгесом (http://www.itblogs.ru/blogs/kolesov/archive/2007/05/23/17239.aspx?CommentPosted=true#commentmessage). Но в ряде случаев, когда компания имеет хороший штат своих программистов и архитекторов, SOA приносит хорошие результаты.

В такой компании внедрение SOAполезно, но может быть осуществлено (скорее всего) только партизанскими методами -- ведь опять-таки зачем может быть нужен SOA понятно ИТ-директору, а не бизнесу.  При этом именно ИТ-директор получает _явный_ выигрыш от полноценного SOA, а вот бизнес получает выигрыш неявный -- только потому, что служба ИТ стала выполнять его поручения лучше.

*)  Я ее уже высказывал на страницах PCWeek в конце прошлого года.

Published 23 мая 2007 г. 22:33 by Vlad Borkus
Filed under: Мысли, SOA

Comments

Первые ласточки конца SOA-волны

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/04/10/_1F043504400432044B043504_-_3B043004410442043E0447043A043804_-_3A043E043D0446043004_-SOA_2D0032043E043B043D044B04_.aspx

Кажется, SOA-«волна» в западной прессе достигла вершины, и начинается фаза спада. Не далее, чем сегодня получил статью ZDNet, где один гуру» обсуждает причины, по которым SOA не сможет быть популярна. В отличие от массы других публикаций статья в целом не глупая.

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

В общем это подтверждает мою мысль, высказанную в предновогоднем обзоре в PCWeek/RE: SOA в первую очередь нужна ИТ-департаменту, и является, по большому счету, его внутренним делом.

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

Остальные будут интегрировать системы «по старинке», но все чаще с использованием Web-сервисов. ESBтакже будет применяться, но, конечно, того светлого будущего, что рисуется в рекламных проспектах Oracle и IBM -- автоматически конфигурируемых из сервисов приложений -- мы в ближайшие годы не увидим ни в одной корпорации. ((В конце прошлого года нами было потрачено достаточно много времени на анализ рынка, чтобы эти выводы сделать определенно. :) ))

Про конец SOA читаем по адресу:  http://blogs.zdnet.com/storage/?p=118&tag=nl.e539

Published 10 апреля 2007 г. 21:50 by Vlad Borkus Edit
Filed under: Мысли, SOA

Comments

Чуть глубже о SOA

Source: http://www.itblogs.ru/blogs/borkus/archive/2006/11/30/soa.aspx

Влад Боркус

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

И не только потому, что можно построить кучу веб-сервисов, и не внедрить у себя в итоге SOA. Этот тезис, безусловно, совершенно справедлив, но лишь чуть приближает к истине.
И не потому, что SOA -- не равно ESB, о чем тоже много говорилось.

А потому, что SOA -- это вообще не про веб-сервисы. Т.е. как бы совсем не про то.

Если говорить формально, то SOA -- это некоторая концепция реинжиниринга и развития корпоративного программного ландшафта. Упоминания этого термина можно встретить где-то в 1996 году у Гартнера. Тогда эти идеи в практической плоскости соотносились с компонентными технологиями.
С тех пор этот набор идей оброс неким опытом и набором где-то использованных приемов, которые в совокупности носят красивое название SOA Governance.
Появились XML и веб-сервисы, и оказалось, что эти идеи неплохо этой технологией дополняются.

Компоненты SOA

В основе SOA действительно лежит понятие сервиса, хотя не только его. Другими компонентами SOA являются фронт-энды приложений, репозиторий описаний сервисов, сервисная шина.

Ключевым для SOA являются наличие сервисов, ориентированных на деловые задачи. В SOA могут быть и масса других сервисов (трансформации, авторизации, и т.п.), но они вторичны.

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

В CORBA, EJB приложение строится из множества маленьких кирпичей. В SOA -- из малого количества больших.

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

Хотя в реальной жизни избежать даже корреляции сервисов не всегда удается, в идеале он должен быть совсем изолированным, и отвечать за все ресурсы, находящиеся под его управлением. Т.е., скажем, если у нас есть сервис, отвечающий за заказы, то изменить заказ в рамках SOA позволительно только одним способом -- через этот сервис. (Вспомним, что SOA -- это про организацию работ).

Чтобы добиться такой изолированности, борцы за SOA-веру предлагают проводить декомпозицию приложений. Или, когда это не возможно, строить так называемые «фасады» -- независимые сервисы, обращающиеся к одному или нескольким нижележащим системам. И работать потом через них.

Ключевым качеством сервиса является его описание. В описании сказано, что за интерфейс (функции) сервис имеет, приведен контракт (на каких условиях возможен доступ), и прочее -- кто его состряпал, какая версия, кто может менять сервис, когда этот сервис доступен, какая у него нагрузочная способность. Это описание совсем не обязательно должно быть на WSDL, например оно может быть на IDL или даже в MS Word. Главное, чтобы оно было.
Естественно, если описание -- в машино-распознаваемом формате, то использовать сервис потом намного удобнее.

Сами сервисы могут быть реализованы в рамках родной инсталляции SOA на разных технологических платформах -- WS, Java, .Net, CORBA. Более того, идея SOA как раз и состоит в том, чтобы обезопасить ИТ-инфраструктуру от смены поколений информационных технологий и стыковать плохо совместимые унаследованные технологии. Скажем, идеологи SOA открыто говорят, что SOAP когда-то отомрет, а ИТ надо будет и дальше жить. Требуется только, чтобы сервисы отвечали формальным требованиям SOA.

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

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

***
Все описания сервисов (описание интерфейса и контракт) обязаны храниться в репозитории.
Если это формальные описания, то система будет более конфигурируемая. Но, стоит заметить, что полноценные репозитории более сложны, а важны больше для B2B-среды, а не контролируемой корпоративной среды.
Но репозиторием может быть, и склад word-документов в файловой системе (это, конечно, экстремальный случай). В конце концов главный элемент в рамках SOA -- это корпоративный разработчик.

Здесь важны два момента. Описание всех интерфейсов должно быть унифицировано, и репозиторий должен быть центральным. Разработчик или динамически конфигурируемый клиент обращаются только к репозиторию, чтобы почерпнуть описания. Иначе -- SOA распадется.

Последний компонент SOA -- это шина сервисов. Это -- не обязательный компонент SOA. И уж, конечно, совсем не обязательно -- это ESB.

Главной задачей шины является технологическа стыковка систем на ее концах. Т.е. если с одной стороны у нас находится SOAP, а с другой -- CORBA, то шина должна обеспечить преобразование формата вызова от одной системы к другой. Например, коммутацию XML-полей на методы CORBA. Мы это можем сделать, так как у нас есть «нейтральное» описание сервиса.
В принципе, в рамках SOA может существовать несколько параллельных шин, скажем она -- асинхронная, а другая синхронная. Или идентичные шины в географички разных филиалах.

Проблемы

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

Есть проблемы с тем, как строить безопасность в такой системе -- на каком уровне должна проводиться аутентификация, авторизация. Особенно все сложно в условиях, когда нельзя сделать общий identity сервис. Опять, есть у людей идеи, но выбор -- по обстоятельствам.

Есть проблемы, о которых упоминал Анатолий, -- как быть с бизнес-объектами. Хотя самый очевидный путь -- это стандартизовать их на уроне шины. Также бизнес-объекты по сути сами являются готовыми сервисами.

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

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

****
PS. Написать этот текст меня подстрекал Анатолий, так что вся ответственность за последствия лежит на нем. Особенно если там отдельные вендор будут кидать в меня камнями :))
Но если статью на форуме сочтут приличной, то я ее попробую доработать и пристроить в какой-нибудь ИТ-журнал.

Published 30 ноября 2006 г. 5:21 by Vlad Borkus

Filed under: Мысли, интеграция, SOA

Comments

EAI-2004 Аналитическая записка по стандартам Web-сервисов.

(c) Владислав Боркус

Web-сервисы: современные стандарты аналитический обзор

Колоссального размера обзор из 10 публикаций. Рассмотрены практически все Web-сервисные стандарты, какие только есть. (PCWeek/RE. Июль-сентябрь 2004)

Введение

Web-сервисы (для краткости, далее будет употребляться сокращение WS) позиционируются в настоящее время как универсальная технология связывания существенно разнородных систем. В ее основе лежит несколько стандартов: XML для описания данных, SOAP для передачи информации с одних систем на другие, WSDL для описания сервисов (в том числе задания типов входных и выходных данных) и UDDI для хранения и предоставления по запросу WSDL-описаний.

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

Все эти направления так или иначе родственны WS, и активно создается некоторая надстройка разных спецификаций, позволяющая вписать эти технологии в мир WS. (Они давно применялись и безо всяких Web-сервисов, но зачастую встраивались в плохо совместимые фирменные продукты вендоров.

В общем наблюдается попытка сделать вполне здоровое решение частной проблемы панацеей от всех бед, в том числе и для областей, для которых WS изначально предназначены не были. Как побочный результат, появляются новые проблемы и, как следствие, происходит взрывной рост спецификаций и технических средств, которые служат для латания искусственно созданных дыр. Каждый производитель ПО стремится занять лидирующее положение на рынке и предлагает собственные уникальные решения, чтобы затем навязать их другим. К сожалению, весовые характеристики компаний, стоящих за этими процессами, таковы, что разработчикам придется жить с этими технологиями, хотят они того или нет.

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

Например, в области управления транзакциями и бизнес-процессами объединились IBM, BEA и Microsoft (условно IBM$) против Sun, Fujitsu и Oracle. Первый из этих лагерей вообще выдвинул инициативу Global Web-services Architecture (GXA), направленную на создание универсального набора стандартов. Кроме того, сейчас идет стандартизация в рамках консорциума Web Services Interoperability (WS-I), который выпустил первый профиль совместимых стандартов (правда только трех-четырех основных). Все это сократило темп роста числа спецификаций. Хотя их все равно много и они не очень-то совместимы, что, конечно, подрывает основу идеологии мира WS. Стоит заметить также, что далеко не все из этих наработок уже нашли применение в программных продуктах -- темп реализации спецификаций в программном обеспечении ниже, чем темп создания новых спецификаций.

В данном обзоре я постараюсь выделить и описать по крайней мере главные из предложенных технологий. Акцент будет не на том, что сделано в области WS (т.е. перечислениях), а на том как именно это работает. Причем, более устоявшимся технологиям (SOAP, WSDL и т.п.) будет уделено меньше внимания, а перспективным, вроде средств разметки транзакций -- больше.

Обзор сделан на базе серии обзоров автора, опубликованных в PCWeek/RE №№27-44 за 2004 год.

Загрузить в PDF