За последние десятилетия трехбуквенные акронимы в ИТ-отрасли распространились в таком количестве, что уже всерьез заговорили о специфическом синдроме, который, естественно, получил собственное трехбуквенное обозначение — RAS (Redundant Acronym Syndrome — «болезнь избыточных сокращений»). Несмотря на то что язык ИТ и так безмерно перегружен сокращениями, усилиями маркетологов постоянно изобретаются все новые и новые. Один из них, SOA (Service Oriented Architecture), всего за несколько лет вошел в число самых растиражированных и надоел больше других. Остается лишь удивляться тому, что заложенная в него идея создания систем с использованием взаимодействующих между собой сервисов так быстро захватила массы — причем задолго до того, как она смогла быть в достаточной мере осознанной. Поиск в Google на service-oriented architecture дает более 35 млн. документов, а на service-oriented — почти вдвое больше, 65 млн. ссылок. Популярность популярностью, но остается озадачивающий любого наблюдателя парадокс: при бросающейся в глаза массовости по-прежнему сохраняется та же самая неопределенность, которая окружает SOA с момента возникновения этого типа архитектуры. Попробуем дать объяснение этому феномену, отдавая себе отчет в том, что предлагаемые рассуждения — лишь одна из возможных версий; скорее всего, есть и другие. Суть выдвигаемой гипотезы состоит в предположении, что нынешняя популярность SOA кроется в интуитивном предвосхищении будущих серьезных изменений в мире ИТ.
Итак, примерно со второй половины 2003 года десятки ИТ-компаний, движимые маркетинговыми устремлениями, заявили о своих продуктовых предложениях, так или иначе воплощающих их собственные подходы к реализации сервисных архитектур. Увы, случившееся оказалось явным фальстартом. Малообдуманные акции «на опережение» были стимулированы взрывом активности аналитиков, прежде всего, отчетами Gartner [1]. Эта аналитическая компания и сегодня выступает в роли оракула, прорицающего будущее, а тогда ее авторитет по части предсказаний находился в апогее. Впрочем жизнь показала, что слепо следовать указаниям даже самых известных аналитиков нельзя. Поддавшись массовому гипнозу и раньше времени вынеся на свое знамя лозунг «Даешь SOA», многие крупные и известные компании поставили себя в крайне неудобное положение и в течение нескольких лет вынуждены были бежать впереди паровоза, на ходу меняя лозунги. Но не все проделанное тогда в связи с SOA ушло в гудок, и к сегодняшнему дню складывается более определенная картина, чем прежде. Год 2007-й принес заметное оздоровление в представления о SOA; последний период оказался отмечен переходом от узкотехнологического представления о SOA к ориентации на потребности бизнеса.
SOA-критицизм
По причине избыточности предложений, обрушивающихся на пользователей на фоне недостаточного понимания сути предлагаемого, у многих из них успело выработаться, мягко скажем, предвзятое отношение к SOA — невзирая на все декларируемые достоинства этой идеи. Доказательство тому — опрос 755 респондентов, проведенный журналом Network Computing. В ответе на вопрос о том, что вы ненавидите и о чем не боитесь сказать безусловным лидером оказались именно сервисные архитектуры. 22% негативно настроенной части аудитории уверены, что SOA — это лишь еще один повод для головной боли, а 20% считают SOA слишком сложной и дорогой игрушкой.
Сомнения в истинности идей SOA все более заметны. Правда, аргументы «SOA-скептиков» пока никак не систематизированы; по большей части они сводятся к тому, что сервисная архитектура есть не что иное, как слегка модернизированные Web-сервисы или ухудшенное (замедленное) средство вызова удаленных процедур. Критике подвергаются не только производители, но и стандарты, положенные в основу SOA. Особенно не повезло протоколу SOAP, вначале именовавшемуся Simple Object Access Protocol, а позже переименованному в Service Oriented Architecture Protocol. (В основном ему достается за слово Simple в прежнем названии: протокол действительно не прост.) Критикуются и стандарты, входящие в группу WS-*, за нестабильность и постоянную эволюцию.
Критические воззрения звучат не только по-английски, но и по-русски. К примеру, гости блога itblogs.ru/blogs/kolesov/archive/2006/11/19/9075.aspx приписывают SOA предназначенность «для развода народа на бабки», обвиняют в том, что «на корпоративном уровне SOA только добавит запутанности». В целом же стиль и приводимая аргументация вызывают в памяти деда из рассказа Василия Шукшина «Космос, нервная система и шмат сала» («Жили раньше без всякого ученья — ничего, бог миловал: без хлебушка не сидели…»)
Справедливости ради стоит заметить, что среди участников этой дискуссии есть и здравые голоса, один из них справедливо заметил: «Проблема, мне кажется, в том, что основные содержательные дискуссии об ИТ случаются не по-русски, а преимущественно по-английски. В итоге в Россию приходят только их отголоски в виде маркетинговых материалов вендоров и их же докладов. Обоснование же этих агитационных выступлений остается за кадром, почему и складывается впечатление о поверхностности и бессодержательности соответствующих концепций». С этим трудно не согласиться. Проблема SOA существенно сложнее, чем ее можно представить, в ней сошлись очень разные технологические, системные и даже философские вопросы, они сплелись в сложный узел, рубить который топором никак нельзя.
И все-таки «да»
Вспомнив еще одного классика советской литературы, Алексея Толстого, удачно пересказавшего Карло Коллоди, зададимся вопросом: «Больной скорее жив, чем мертв, или больной скорее мертв, чем жив?»
Приходится признать, оснований для пессимистичных прогнозов по отношению к SOA вполне достаточно, поскольку пока количество успешных проектов, построенных на принципах SOA, по отношению к проваленным проектам находится в неутешительной пропорции один к десяти (данные британской аналитической компании Quocirca). Но, признавая этот печальный факт, эксперты той же Quocirca считают, что основная причина неудач заключена не в идеологии SOA, а в ее неверной интерпретации теми, кто первыми взялись за это дело. Неудачи кроются, прежде всего, в непонимании фундаментальных принципов слабой связанности сервисов (loose coupling): многие разработчики путают потенциальную возможность вызова отдельных сервисов с тем, что сервисы могут вызывать ad-hoc, т. е. произвольно, «по случаю». Полноценная организация SOA требует более радикальных решений, в частности создания масштабируемых реестров, действующих в условиях автоматического согласования в соответствии с заключенными договоренностями относительно того, как сервисы вызываются. Из-за неполноценной реализации информационные системы получаются не слабо, а сильно связанными (tightly coupled), и, как следствие, теряются преимущества сервисного подхода. Упрощение и жесткие связи приводят к тому, что упускается из виду главное, ради чего и были придуманы сервисы, — возможность многократного использования заложенной в них функциональности.
К тому же, SOA — не продукт. Неизбежная необходимость в большой собственной работе специалистов компаний, решивших внедрять SOA, дает еще один повод для критики. Многие SOA-скептики сравнивают эту архитектуру с «моделью для сборки» (kit-car — набор, позволяющий собрать оригинальную конструкцию автомобиля в собственном гараже).
Вместе с тем более серьезный и по возможности объективный анализ свидетельствует, что больной «скорее жив». Одно из самых полных и всесторонних исследований истинного состояния дел в области SOA выполнила аналитическая компания Aberdeen Group. В ее 40-страничном отчете Enterprise Service Bus and SOA Middleware потенциальные пользователи SOA
разделены по своему размеру на три группы — SOA Lite, SOA ERP и SOA Enterprise, что условно соответствует малым и средним предприятиям, крупным предприятиям и предприятиям, входящим в престижные списки, подобные списку Forbes. Организации разных групп различаются по степени «погруженности» в SOA. Среди тех, у кого доход превышает 1 млрд. долл. в год, 20% имеют более чем годовой опыт работы с сервисными архитектурами; при меньшем годовом доходе, но превышающем 50 млн. долл., этот показатель падает до 6%, а в «младшей весовой категории» — до 3%. Примерно ту же картину можно наблюдать во взглядах компаний на использование корпоративной сервисной шины (Enterprise Service Bus, ESB). Только 7% из числа крупных корпораций не рассматривают эту технологию в качестве своей перспективы, однако большинство средних и более 80% небольших предприятий не имеют планов по внедрению ESB. Такое распределение свидетельствует об адаптации небольшими и средними предприятиями стандартов SOA и отдельных программных решений, но не общего стиля разработки систем подобной архитектуры.
SOA и бизнес
Начиная с 2006 года, т. е. примерно четыре года спустя после первой волны увлечения SOA, возникла вторая волна, вызванная уже не предвосхищением будущего, а практическими обстоятельствами. Наконец-то пришло осознание идеологической близости архитектур бизнеса и SOA. Действительно, вне зависимости от предметной области любой бизнес — это в конечном итоге развитая система сервисов. А раз так, то для автоматизации бизнеса ему должна быть поставлена в соответствие информационная система, построенная на точно таких же сервисных принципах; тогда предмет автоматизации и средства автоматизации будут «изоморфны» друг другу. Если сервисы присутствуют и в автоматизируемой системе и в системе автоматизации, то сервисный подход — во всяком случае, так это видится сейчас, — поможет перекрыть пропасть, разделяющую бизнес и информационные технологии.
Любопытно, что в понимании некой диалектической взаимосвязи между сервисами в бизнесе и сервисами в информационных технологиях сработала своеобразная обратная связь. Сначала заговорили о Web-сервисах, затем была выработана сервисная модель в приложении к SOA, а еще позже идея сервисов распространилась на бизнес; таким образом, цикл замкнулся. (Детальнее такого рода соображения рассмотрены в большой статье Робина Чена «Определяем сервисы бизнеса: SOA с корпоративных позиций», опубликованной в журнале SOA Magazine [2].)
Не случайно тема взаимосвязи SOA и бизнеса становится лейтмотивом многих публикаций и конференций. К примеру, на сайте www.accelacomm.com можно прослушать целый курс Business Transformation through SOA: Evolve your IT Infrastructure, подготовленный совместно аналитиками Gartner и специалистами компании IONA Technologies.
Выступая на конференции SOA Impact, прошедшей в апреле в Орландо, Стивен Миллс, вице-президент корпорации IBM по программному обеспечению, сказал: «Если бы сдвиг по направлению к сервисной ориентации был только технологическим, то обвинения в навязывании очередного модного словечка были бы справедливы. Но мы наконец поняли, как реальный бизнес связан с SOA, и теперь мы можем сказать, что вступаем в эпоху ‘компьютерных систем, направляемых бизнесом’ (business-driven computing). Нам предстоит проделать сложную операцию по разделению бизнес-процессов и монолитных приложений, которых сделано немало. До тех пор, пока не произойдут необходимые культурные изменения, пользователи не смогут создавать динамические бизнес-процессы нового поколения, соответствующие следующему поколению представлений о моделировании бизнеса».
Стоит заметить, что достаточно полное представление о большинстве значимых публикаций, так или иначе связанных с SOA, можно получить, если следить за ежедневным дайджестом SOA Digest (soadigest.com).
«Алгебра» сервисов
Томас Эрл, автор серии книг Service-Oriented Computing Series from Thomas Erl, выпущенной издательством Prentice Hall (www.soabooks.com), и редактор сайта журнала SOA Magazine (www.soamag.com), пожалуй, первым попытался обобщить рассуждения о том, что же такое ориентация на сервисы. Хотя Эрл, выстраивая свою теорию, исходил из взглядов, диктуемых лишь компьютерными представлениями о SOA, его усилиями сложилась целостная картина, которую теперь переносят и на сервисы вообще, когда рассматривают их с точки зрения бизнеса. Картина эта оказалась настолько удачна, что в лексикон специалистов вошло выражение «сервисные принципы Томаса Эрла».
Но, прежде чем говорить об этих принципах, нужно сказать несколько слов о самом слове service. В английском языке оно многозначно, диапазон значений распространяется от вязки собак до прохождения воинской службы. Но в данном случае ближе всего оказывается его исходное значение, берущее начало от средневекового английского servise, в свою очередь происходящего от латинского servus, то есть «раб». В ряде языков сохранилось приветствие, звучащее как «сервус» и означающее «к вашим услугам». Отметим, что в данном контексте сервисы не следует путать с тем, как в экономике или маркетинге сервисы рассматривают в качестве нематериальной формы представления товара.
Ключевым понятием для определения сервисной ориентации является принцип Separation of Concerns, обычно переводимый как «разделение ответственности», хотя можно перевести и как «разделение сфер влияния». Значение термина concern точнее всего передает его юридическая интерпретация — «доля» или пай. В данном контексте concern удобно представить как «долю функциональности» решения общей задачи.
По Эрлу, для того, чтобы архитектура стала ориентированной на сервисы, сами сервисы должны удовлетворять следующим критериям.
Сервисы слабо связаны с бизнесом и между собой. В контексте автоматизации мера связанности отражает зависимость в отношениях между предметом автоматизации и поддерживающей автоматизируемые процессы логикой. В жестко связанных простых технических системах автоматизации эта связь является абсолютной; так было с первого регулятора Уатта и до современных технических систем. В конечном итоге степень связанности определяется природой автоматизируемого объекта: чем он проще, тем проще регулятор. Бизнес с системной точки зрения сложен, его можно представить в виде сервисов и автоматизировать посредством отдельных сервисов, отношения с которыми выстраиваются на основе определенных контрактов. Архитектура бизнеса нестабильна, он подвержен непрерывному потоку событий. Поэтому полноценным средством для его автоматизации может быть архитектура, управляемая или «движимая событиями» (Event Driven Architecture, EDA), а полноценно реализовать EDA можно только с использованием SOA. Смежный смысл словосочетания loose coupling относится к определению отношений между системными компонентами. Сегодня этот термин широко используется в лексиконе ИТ-специалистов; я же впервые услышал его от Адама Босуорта в его бытность техническим руководителем компании BEA Systems. В то же время нет ничего удивительного в том, что впервые термин loose coupling предложил известный специалист по менеджменту Карл Вейк в статье «Управление изменениями в среде слабо связанных элементов» (The Management of Change Among Loosely Coupled Elements) в 1982 году. На примере этого качества сервисов мы видим, насколько сервисная идея близка и ИТ, и бизнесу.
Взаимодействие сервисов определяется контрактами. Базисом для сервисов, в зависимости от их природы, могут быть узаконенная (допустимая) или техническая совокупность правил. Это положение относится прежде всего к сервисному контракту. В этом контракте в случае технических сервисов, определен программный интерфейс, коммуникационные требования, ограничения, свойства, политика использования и даже определенные преференции. Тот программный модуль, который хочет стать пользователем сервиса, должен следовать контрактным условиям, причем он должен рассчитывать и на возможную недостаточную «компетентность» сервиса, то есть на его неспособность в полной мере выполнить желания заказчика.
Сервисы изолируют внутреннюю логику от окружающего мира. Вся информация о сервисах, за исключением контрактной, скрыта от окружения; этим, собственно, и обеспечивается слабая связанность и возможность интерпретировать сервис как «черный ящик». Преимущество такого представления заключается в минимизации влияния на клиентские программы, использующие сервисы, в случае каких-то действий по модернизации внутри сервисов.
Перечисленные признаки сервисов — слабая связанность, контрактное взаимодействие и внутренняя замкнутость — образуют триаду, на основе которой строится взаимодействие между сервисами (рис. 1). Такое взаимодействие отличается предсказуемостью, но одновременно обладает достаточным потенциалом для динамической перестройки инфраструктуры. Эта триада обеспечивает главные достоинства SOA.
Сервисы могут использоваться многократно. Один и тот же сервис может быть использован вызывающими его сервисами, то есть он может использоваться многократно, как любая функция или подпрограмма (рис. 2). (В отечественной литературе почему-то принято переводить термин reusable как «повторно используемый», что не вполне точно: в частном случае написанный когда-то сервис действительно может быть использован вторично, но более существенно, что к одному сервису допускается сразу несколько одновременных обращений.)
Сервисы не имеют собственного состояния. Сервис должен обладать свойством, которое по-английски называется stateless, а в теории автоматического регулирования обозначается термином «автомат без состояния». Если сервис в той или иной форме сохраняет информацию о своем состоянии, то оказывается привязанным к выполняемому им заданию. Для перехода к следующему заданию ему нужно освободиться от накопленного состояния, а это требует ресурсов, да и вообще не всегда возможно. Отсутствие собственного состояния обеспечивает нейтральность по отношению к модулям, обращающимся к сервисам. В отличие от самоуправления отсутствие состояния не может быть абсолютным; всегда на какой-то момент времени сервисы сохраняют что-то в своей памяти. Для многократного использования они должны «уметь» восстанавливать исходное состояние.
Сервисы должны быть обнаруживаемыми. Это свойство сервисов в массовом порядке — пожалуй, даже чрезмерно — обсуждалось, начиная с первых шагов SOA наряду с протоколами SOAP, UDDI, WSDL. Суть его в том, что приложение, ориентированное на сервисы, не должно быть перегружено реестрами сервисов, механизмами их обнаружения. Для этой цели должна быть предусмотрена специальная поддержка, а приложение должно быть сосредоточено на собственном функционале. Условия, зафиксированные в предложении для контракта, должны позволять потенциальному клиенту найти нужный ему сервис и подключить его вручную или автоматически.
Слабая связанность, контрактное взаимодействие и внутренняя замкнутость образуют основу взаимодействия сервисами — такое взаимодействие отличается, с одной стороны, предсказуемостью, а с другой — обладает достаточным потенциалом для динамической перестройки инфраструктуры.
«Мавр сделал свое дело»
Долгое время пониманию сути SOA мешало то, что обязательным при использовании слова «сервис» был префикс Web. Но, что отрадно, в определении SOA, приведенном в Wikipedia в редакции июня 2007 года, мы наконец находим: «SOA — это архитектура, не привязанная ни к одной специфической технологии, она может быть реализована с использованием технологий REST (Representational State Transfer), RPC (Remote Procedure Call), DCOM (Distributed Component Object Model), CORBA (Common Object Request Broker Architecture), Web Services (точнее, прикладной программный интерфейс Web API) или WCF (Windows Communication Foundation). Ключом к созданию SOA являются независимые сервисы с определенным интерфейсом, способные выполнять стандартным способом предписанные им функции без необходимости наличия каких-то предварительных знаний ими специфики вызывающей их задачи».
Подобное определение могло появиться только сейчас, а до этого, скорее всего от полного непонимания подлинной природы сервисов как таковых, на протяжении нескольких лет SOA отождествлялась исключительно с Web-сервисами, что совершенно неверно. Для создания сервисной архитектуры не столь важно, какими именно технологическими средствами материализуются требуемые сервисы; собственно архитектурная идея не зависит от природы сервисов. Однако в большинстве своем евангелисты SOA, обращая слушателей в свою веру, сами не понимали сути своего предмета, об этом свидетельствует следующее наблюдение. Вот уже на протяжении нескольких лет на различных конференциях, семинарах и встречах я пытался обсудить взаимоотношения между сервисной архитектурой и Web-сервисами, но ни разу не удостоился содержательного обсуждения — обычно даже самые уважаемые собеседники отделывались общими словами.
Web-сервисы оказались востребованными на первом этапе, поскольку почти полностью удовлетворяют приведенным выше критериям. Они слабо связаны, работают на контрактном принципе, их внутренняя логика скрыта от окружающих, они поддаются композиции. Возможность многократного использования поддерживается стандартом WSDL и схемой XSD, самоуправление и отсутствие собственного состояния заложено в принципы проектирования. Протокол SOAP поддерживает многократное использование, отсутствие собственного состояния и самоуправление. Следовательно, опираясь на них, можно построить SOA; но это вовсе не значит, что для этого нельзя выбрать какую-то иную технологическую платформу. При этом надо признать, что роль Web-сервисов чрезвычайно важна: именно благодаря ним в обиход ИТ-специалистов вошло слов «сервис».
В неявной — или, скорее, зародышевой — форме архитектура SOA существовала с начала 90-х годов. Технологии CORBA и DCOM также строились на контрактной основе, были в определенной мере слабосвязанными, что составляло их главное преимущество по сравнению с монолитными архитектурами. Но слабостью DCOM оказалось то, что это архитектурное направление было очевидно ориентировано на единственного вендора. Что же касается подхода CORBA, то декларированный как независимый от вендоров, он на самом деле оказался подчинен интересам некоторой группы вендоров и не вышел на уровень общепризнанного стандарта.
Для настоящего успеха SOA не хватало двух вещей — универсальных стандартов и языка eXtensible Markup Language (XML). И вот в нужный момент в нужном месте обнаружились основные компоненты Web-сервисов — язык описания Web-сервисов Web Services Description Language (WSDL), стандарт универсального описания, обнаружения и интеграции Universal Description, Discovery, Integration (UDDI), а также протокол SOAP. С их помощью удалось реализовать классическую треугольную схему сервисной архитектуры (рис. 3) — «нашел — упаковал — опубликовал» (find — bind — publish).
Серьезный удар по монопольному положению Web-сервисов как основы SOA нанесли крупные производители, увидевшие в этой архитектуре большие перспективы. Естественно, они не пошли по пути глобальных сервисных репозиториев, а предпочли использовать собственные программные продукты, адаптируя их к работе с сервисами и называя свои системы «сервис-ориентированными». Как правило, при этом происходит модернизация, интерфейсы Web-сервисов прикладываются к уже существующим продуктам, адаптеры Web-сервисов включаются в собственные системы промежуточного слоя, основанные на обмене сообщениями. С наступлением 2007 года начался активный процесс адаптации сервисного подхода к накопленному технологическому багажу. Своеобразие этого подхода заключается в том, что реализации архитектуры SOA получаются упрощенными, частными и не удовлетворяющими критериям Эрла. Если выразить происходящее в терминах общественных процессов, то на смену SOA-революции пришла следующая волна с элементами контрреволюционности.
SOA и моделирование бизнеса
На конференции в Орландо, о которой речь уже шла выше, Стивен Миллс много говорил о «компьютинге, движимом бизнесом» (business-driven computing). Он особо обратил внимание на предоставляемую SOA возможность для моделирования бизнеса и бизнес-процессов. Но что можно назвать моделью? В технических системах или в научных приложениях все проще и привычнее, там для представления модели может быть использован тот или иной математический аппарат (разумеется, это условная простота, использованные математические методы могут быть сами по себе достаточно сложными).
В бизнесе математическое моделирование имеет ограниченное применение на макроуровне, где можно абстрагироваться от человеческого фактора. На уровне же практических приложений, где используются ИТ, моделирование ограничено тем, что основным устройством бизнеса как моделируемой машины является офисный работник, осуществляющий бизнес-процессы. При этом он сам не ощущает себя винтиком, привязанным к кому-то процессу; он находится внутри, для него бизнес-процесс — это переговоры, встречи, обмен документами, а если он занимает достаточно высокую должность, то еще и анализ, оценка и принятие решений. Современные технологии расширяют спектр деятельности офисных работников, теперь они пользуются электронными таблицами, Web-ресурсами, а также такими подручными приемами, как диаграммы, графические средства, выражающие идеи, в их распоряжении графики потоков работ, календари, расписания и другие формы представления слабоструктурированных данных.
Но при всем видимом разнообразии деятельность такого работника тем не менее можно представить как своего рода «сервис», удовлетворяющий приведенным критериям, а модель бизнеса — как совокупность таких сервисов. Такое представление бизнеса может показаться упрощением, но оно гораздо продуктивнее, нежели бытовавшие прежде определения бизнес-модели типа «набор действий, направленных на достижение целей бизнеса». Основное достоинство такого «человеческого» подхода к сервисной модели заключается в том, что ей можно поставить в соответствие компьютерную модель SOA. Как следствие впервые за всю историю компьютеров в бизнесе удается преодолеть разрыв между бизнесом и ИТ. Этот разрыв возник из-за параллельного сосуществования двух типов мышления — технического, присущего представителям ИТ-сообщества, и прагматического, свойственного менеджерам. Использование SOA позволяет свести вместе два стиля мышления, два представления о том, что такое модель бизнеса, и рано или поздно дает возможность образовать единую команду, работающую на общую цель.
Модельный подход позволит расставить все по своим местам. Он должен вызвать заметную трансформацию в представлениях о своей деятельности архитекторов информационных систем. Отныне они вынуждены в большей степени стать архитекторами, чем инженерами, проектировать, подчиняясь процессам, направленным извне вовнутрь (outward-in), а не наоборот (inward-out), в большей степени ориентироваться на человеческие потребности, видеть информационные системы глазами пользователя. Примерно то же относится и к производителям технологий: период, когда они диктовали свои условия пользователям, закончился. Руководители бизнеса, со своей стороны, должны осознать, что SOA не является аппаратным или программным обновлением существующих информационных систем, это вовсе не продукт. Можно сказать, что путь к SOA — это прежде всего взаимные обязательства двух сторон, ставящие своей целью создание согласованной модели, понятной обеим сторонам. Для представителей ИТ создание SOA — это не отдельные шаги, а философия непрерывной интеграции технологий с бизнесом. Для представителей бизнеса — это более широкие возможности для управления и человеческими и технологическими ресурсами. Большинством экспертов ориентация на бизнес-модели рассматривается как важнейшее условие успешного внедрения SOA.
SOA как этап компьютерной эволюции
То обстоятельство, что архитектура SOA оказалась востребованной бизнесом, находится на подъеме, убеждает, но не объясняет. Эта система аргументов не дает ответа на простой вопрос, является ли SOA очередным искусственным порождением или закономерностью. Чтобы убедиться во втором, стоит, как во многих подобных случаях, обратиться к истории. И начать следует с Алана Кая, который еще в 70-е годы принялся развивать объектные технологии, используя объекты в качестве переносчиков семантики, а не простых данных. Его последователем, разработчиком среды для объектно-ориентированного языка Smalltalk на IBM PC был Стив Бурбек. Он развивал объектные технологии в собственном направлении и в конечном итоге пришел к идее SOA. С большой степенью достоверности можно утверждать, что первое упоминание сервисных архитектур можно найти в его статье «Дао сервисов электронного бизнеса» с подзаголовком «Эволюция Web-приложений в сервис-ориентированные компоненты с Web-сервисами», датированной октябрем 2000 года. Эта статья — дань своему времени. Стоит напомнить, что в конце XX века мы пережили короткий период, который остался в памяти в связи массовым увлечением так называемым «электронным бизнесом», взаимодействием между бизнесами (business-to-business, B2B) и другими возможностями, открывшимися в связи с ростом популярности Глобальной сети; и эта статья отражает многие заблуждения, свойственные тому периоду. Пожалуй, самое существенное в ней — высказанное Бурбеком предположение, что для гибкой организации взаимных услуг между отдельными бизнесами может быть выстроена архитектура, названная им Service-Oriented Architecture, основанная на Web-сервисах. Он же первым предложил не только название, но и трехзвенную схему, ставшую в последующем классикой SOA. Схема эта состоит из поставщика услуг, брокера-посредника и получателя услуг:
-
поставщик публикует сведения о предоставляемых им услугах;
-
посредник регистрирует, классифицирует и осуществляет поставку услуг;
-
потребитель, используя услуги посредника, находит нужные ему услуги и внедряет их.
Свои довольно общие рассуждения о SOA Бурбек опубликовал еще до кризиса «доткомов». Нет ничего удивительного, что его изложение соответствовало бытовавшим в то время представлениям, когда рисовалась глобальная картина с какими-то распространяющимися на все пространство Internet репозиториями сервисов и тому подобными гигантскими механизмами. Чем вся эта утопия закончилась, хорошо известно, и то, что писалось тогда, в 2007 году кажется наивным. Но Бурбек этим не ограничился, а продолжил свои исследования, названные им «многоклеточными компьютерными системами» (Multicellular Computing). В 2004 году он опубликовал первую, а в 2007-м — вторую редакцию работы «Сложность и эволюция компьютерных систем, биологические принципы для управления эволюционирующими системами» (Complexity and the Evolution of Computing, Biological Principles for Managing Evolving Systems).
Аналогия с переходом от одноклеточных организмов к многоклеточным, случившимся в природе сотни миллионов лет назад, приходит на ум не только в связи с SOA. К тому же умозаключению подталкивает появление многоядерных процессоров, кластеров из лезвий и некоторые другие примеры. Бурбек подошел к этому вопросу как настоящий ученый, показав, что SOA— отнюдь не случайность, а вполне закономерный этап процесса эволюции ИТ. n
Литература
-
Yefim Natis, Massimo Pezzini, Predicts 2003: SOA to Stir Up Application Server Market. Gartner Report, Dec. 4, 2002.
-
Robin Chen, Defining Business Services: SOA from a Corporate Perspective. SOA Magazine, May 2007.
О термине Separation of Concerns
Разделение ответственности (Separation of Concerns, SoC) — один из основополагающих принципов инженерии вообще и программной инженерии в частности. Разделение одного монолитного решения задачи на отдельные взаимодействующие решения подзадач позволяет снизить системную сложность, повысить надежность, адаптивность, удобство эксплуатации и обеспечить возможность повторного использования программ. Методы SoC реализуются в аспектно-ориентированном и субъектно-ориентированном программировании. Термин Separation of Concerns был впервые предложен Эдскером Дейкстрой в 1974 году. Однако Дейкстра, будучи великим программистом, тем не менее использовал его не в приложении к программированию, а для описания собственных представлений о научном мышлении. В его современном значении для программной инженерии термин Separation of Concerns был использован Крисом Ридом в книге Elements of Functional Programming (1989).
